Author name: G360 Technologies

NIST Launches Initiative to Define Identity and Security Standards for AI Agents Here is a scenario playing out in enterprises right now. An AI agent is deployed to automate routine work: scheduling meetings, querying databases, updating tickets, and calling external APIs. It operates across internal systems, makes decisions about which tools to use, and executes actions on behalf of users. Then an auditor asks a simple question: who authorized the agent to access those systems, and how can its actions be traced? For most organizations today, there is no consistent answer to that question. NIST wants to change that. The Problem With How We Think About Software Identity Traditional software identity models were built around clearly defined applications and services. You have a service account, a set of permissions, and an audit log. The boundaries are known. AI agents break that model. These systems don’t just execute predefined tasks. They operate with a degree of autonomy, deciding which tools to call, which APIs to query, and which actions to take in sequence. An agent handling a user request might touch five internal systems and two external APIs in a single session, none of which were explicitly anticipated when the agent was deployed. That creates a governance gap that existing identity and access management frameworks weren’t designed to address. Who, or what, is the agent? What is it authorized to do? If something goes wrong midway through a chain of actions, where does accountability land? These are operational questions that enterprises deploying agent systems are already encountering. What NIST Announced In February 2026, NIST’s Center for AI Standards and Innovation launched the AI Agent Standards Initiative, a coordinated program to develop security, identity, and interoperability standards for autonomous AI agents. The initiative is organized around three areas of work. The first is facilitating industry-led standards development and maintaining U.S. participation in international standards bodies working on AI agent specifications. The second is fostering open source protocol ecosystems for agent interoperability, supported in part through research programs like the National Science Foundation’s work on secure open source infrastructure. The third focuses on foundational research in agent security and identity: authentication models, authorization frameworks, and evaluation methods for autonomous systems. Two early deliverables are already in progress. NIST issued a Request for Information on AI Agent Security, with responses due March 9, 2026, seeking ecosystem input on threats, mitigations, and evaluation metrics. Separately, the National Cybersecurity Center of Excellence published a concept paper titled Accelerating the Adoption of Software and AI Agent Identity and Authorization, open for public comment until April 2, 2026. Sector-focused listening sessions covering healthcare, finance, and education are planned for April. The Four Technical Problems NIST Is Trying to Solve Agent identity. The concept paper explores treating AI agents as distinct entities within enterprise identity systems, with unique identifiers and authentication mechanisms similar to how service accounts or non-human identities are managed today. This would give agents a traceable presence in the systems they interact with, rather than operating invisibly under a user’s credentials or a shared service account. Authorization and access control. Scoping agent permissions is harder than it sounds. An agent authorized to read a database shouldn’t necessarily be authorized to write to it, even if the underlying task seems to require it. The concept paper examines how existing IAM standards could be extended to support more granular, dynamic permission models for agents operating across multiple systems. Action traceability and logging. If an agent takes a sequence of actions across several systems in a single session, organizations need logs that can reconstruct what happened, in what order, and under what authorization. This is foundational for security monitoring, incident response, and audit. Without it, agentic systems are effectively a black box from a governance perspective. Interoperability and protocol design. Agents built on different platforms need consistent ways to communicate with tools and services. Without shared protocols, every enterprise deployment becomes a bespoke integration problem, and security practices fragment across vendors. NIST plans to engage industry and open source communities to identify barriers and support shared technical approaches. Why This Matters for Enterprise Teams The initiative is early-stage, but the direction is clear: AI agent architecture is going to be subject to standardization pressure, and the technical decisions being made now will influence what those standards look like. A few practical implications worth tracking: Non-human identity management is becoming a first-class problem. Enterprises are already managing service accounts, API keys, and OAuth tokens. Agents add a new layer of complexity because their behavior is less predictable than traditional software. IAM teams will likely need to think about agent identities the same way they think about privileged service accounts, with tighter scoping and more aggressive monitoring. Audit requirements are coming. Whether driven by regulation or internal governance, detailed logs of agent actions are going to become a baseline expectation for any enterprise deploying autonomous systems in sensitive environments. Building that logging infrastructure now is easier than retrofitting it after an incident. Fragmentation is the near-term risk. Until interoperability standards mature, enterprises integrating agents from multiple vendors are effectively building on unstable ground. The NIST initiative signals that this will eventually be addressed, but the timeline for stable, broadly adopted standards is measured in years, not months. The Honest Limitations The initiative is a coordination and research effort, not a standards release. The technical models for agent identity and authorization are still being shaped by the RFI and comment process. How quickly interoperable protocols will emerge, and how broadly they will be adopted across vendors and platforms, is genuinely uncertain. What NIST is doing is establishing the organizational and research infrastructure to make standardization possible. For a governance gap this foundational, that is probably the right starting point. But enterprises deploying agents today are doing so ahead of the standards, which means enterprises deploying agents today must design their own governance and control approaches. Further Reading NIST Center for AI Standards and Innovation: AI Agent Standards Initiative announcement NIST NCCoE

When Code Scanners Don’t Understand What Code Does Application security testing has a structural problem that has been quietly tolerated for years. Static analysis tools are pattern matchers. They scan code looking for shapes they recognize: a known SQL injection fingerprint, a hardcoded credential, a weak cipher reference. If the vulnerability fits a known rule, they catch it. If it doesn’t, it passes through. That model worked well enough when applications were monolithic, and most vulnerabilities were obvious. It works considerably less well when your application is a mesh of distributed services, third-party APIs, and shared libraries, where the dangerous condition only appears when several components interact in a specific way. A new category of tools is approaching this differently. Instead of scanning for patterns, they reason about behavior. The early architecture suggests the distinction is meaningful. The False Positive Problem False positive rates in static analysis tools have been studied extensively. In some enterprise environments, 50 to 60 percent of alerts turn out to be noise. Security teams know this. Developers know this. The result is alert fatigue: scanners keep running, dashboards fill up, and findings get ignored. The issue is not the tool itself but the detection model it relies on. Rule-based detection is precise only when the rule perfectly describes the vulnerability. The moment a vulnerability is novel, contextual, or logic-based, the rule doesn’t fire. The problem is compounding. AI coding assistants now contribute a meaningful share of enterprise code changes. Development pipelines that once pushed code weekly now push hourly. The backlog of unreviewed code is growing faster than security teams can clear it with current tooling. How Reasoning-Based Analysis Works Anthropic’s Claude Code Security is an early production implementation of this approach. The core premise: instead of asking whether code matches a known bad pattern, ask what the code does and whether that behavior creates risk. The system uses Claude Opus 4.6 to analyze repositories through a multi-stage pipeline. Each stage differs from traditional pattern-based scanning. Stage 1 Context construction Before analysis begins, the system builds a representation of the application: selected files, diffs, call chains, architectural summaries. The model gets a picture of how components relate to each other, not just what each file contains in isolation. Cross-component vulnerabilities require cross-component context. Stage 2 Behavioral reasoning The model traces how data enters the system, how it propagates across components, and what controls are applied along the way. Authentication flows. Authorization checks. Where sensitive operations occur. This approach is intended to detect vulnerabilities that rule-based scanners often miss: a broken access control path that only appears when one service makes an assumption about what another already validated, or a business logic error that is perfectly valid code doing exactly the wrong thing. Stage 3 Self-adversarial verification After the model proposes candidate vulnerabilities, additional reasoning passes attempt to disprove them. The system challenges its own findings before surfacing them. Candidates that fail this adversarial check are discarded. What remains gets a severity rating and a confidence score, both presented to the developer alongside the finding. Suggested patches are generated for each confirmed finding, but the system does not apply them automatically. A developer must review and approve every proposed change before it is committed. Why the Timing Is Right Application security tooling was built for a different era: monolithic applications, slower release cycles, and security reviews that happened after code was written. The development landscape changed. Much of the tooling did not. Modern applications are architecturally complex in ways that challenge rule-based detection at a fundamental level. Vulnerabilities emerge from interactions between distributed services, not from a single bad line. A data flow passes through five microservices before it touches a database. Writing a rule that reliably catches an injection across that path is often not tractable. Reasoning-based analysis attempts to sidestep the rule-writing problem and asks the question directly: given how this system behaves, where can it be exploited? That framing may scale better as architectures grow more distributed and codebases grow faster than rules can be written to cover them. What Changes for Security Teams The workflow implications are significant. CI/CD pipelines that currently run static analysis as a gate check will likely need to be redesigned. The pattern shifts from detection-only to a full loop: detection, diagnosis, patch suggestion, human approval, deployment. The security tool becomes an active participant in remediation, not just a reporter of violations. Security analysts will see fewer alerts but more detailed findings. Instead of triaging hundreds of rule violations, they review a smaller set of findings that each include a reasoning narrative, an exploit path, and a proposed fix. The role shifts from alert triage toward verification and governance. For organizations running microservices, context integration becomes a real infrastructure requirement. These systems need repository structure, dependency graphs, and architecture metadata to work well. Some organizations will need to build cross-repository context layers before reasoning-based analysis can operate effectively at scale. Risks That Deserve Attention Non-determinism is a genuine concern. The same analysis run twice may produce slightly different findings. That complicates auditability and reproducibility for enterprises with compliance requirements around security tooling. Automation bias is already documented in adjacent contexts. Studies have recorded developers rapidly approving large AI-generated pull requests without thorough review. The same dynamic could appear with AI-generated security patches. A well-formatted, confident patch suggestion can still be wrong. The human approval loop only works if the approval is substantive. Hallucinated artifacts present a specific risk worth flagging. Language models can invent package names and API references that do not exist. Attackers have already exploited this in other contexts by registering hallucinated package names in public repositories. A security tool that hallucinates a remediation dependency could introduce the very type of vulnerability it was trying to address. Resource cost is also a practical constraint. Running a large model across an entire repository on every commit is computationally expensive. For large codebases with high commit frequency, the cost and latency profile may require architectural changes to

Treasury’s New AI Risk Framework Gives the Financial Sector a Governance Playbook Here is the problem every bank technology team knows. The model gets built fast. Governance takes forever. And when regulators ask for evidence that someone thought carefully about bias testing, data lineage, and explainability before deploying an AI credit underwriting system, the answer is usually a collection of emails, a few internal memos, and a hope that nobody asks too many follow-up questions. In February 2026, the U.S. Department of the Treasury released the Financial Services AI Risk Management Framework FS AI RMF) to close that gap. Built with the Cyber Risk Institute and shaped by input from more than 100 financial institutions and public agencies, the framework does something most AI governance guidance has not attempted. It gets specific. Where the NIST Framework Ends The NIST AI Risk Management Framework, released in 2023, gave the industry a solid four-function structure: Govern, Map, Measure, and Manage. It defined the vocabulary of AI risk. What it deliberately did not do was tell a bank’s compliance team what evidence to produce when an examiner walks in the door. That is not a criticism. The NIST framework was designed to be cross-sector and principles-based, which is exactly what made it adoptable across industries. But financial services are not a cross-sector environment. Banks operate under model risk management requirements. They have consumer protection obligations. They run under continuous supervisory scrutiny. Abstract principles do not satisfy an OCC examiner asking for validation documentation. The FS AI RMF takes the NIST structure and fills in that operational layer. The same functions remain. Substantially more operational detail about how those functions can be implemented. 230 Controls Is a Lot. Here Is How It Works. The framework introduces roughly 230 control objectives, which may initially appear complex, until you understand how the implementation is structured. Institutions do not start by reading all 230. They start by taking a questionnaire. The AI Adoption Stage Questionnaire classifies an organization by the extent and risk profile of its current AI deployments. The answers determine which controls apply. A community bank running a single vendor fraud detection tool has a very different control set than a large bank with internal model development teams building credit and trading systems from scratch. From there, the toolkit has four main components: Risk and Control Matrix: Maps risk statements to the relevant control objectives, organized by adoption stage. This is where institutions figure out which controls actually apply to them. Guidebook and Control Reference Guide: Operational guidance on how to implement each control, including concrete examples of evidence that satisfies the requirement. Guidance intended to support audit preparation and supervisory review. Quick Start Guide: A smaller control set for institutions early in their AI adoption. It establishes a governance baseline without requiring the full framework on day one. Adoption Stage Questionnaire: The entry point that determines scope. Everything else flows from this. The implementation sequence follows a five-step loop: Assess, Customize, Implement, Integrate, Evolve. The last step matters. AI systems drift, get retrained, expand into new use cases. The framework expects controls to evolve alongside the systems they govern. What the Controls Actually Cover The control set spans the full AI lifecycle across several operational domains. For a bank deploying AI in lending decisions, this translates into concrete governance requirements across four areas. Model lifecycle management Controls address model design, testing, monitoring, drift detection, explainability thresholds, and rollback procedures. For credit underwriting, this means documented processes for catching when a model stops performing as expected and clear steps for what happens next. Consumer protection Fairness, explainability, and data documentation requirements sit here. If your model is making credit decisions, you need to be able to explain those decisions, document what data went into training it, and demonstrate that fairness testing was actually performed rather than assumed. Resilience and security Cybersecurity exposure, adversarial risks, and vendor dependencies all get coverage. AI systems introduce additional security considerations, including model inversion, adversarial inputs, and dependencies on external foundation models. Third-party governance This one is particularly relevant for smaller institutions. Most community banks and regional institutions are not building models in-house. They are buying or licensing them from technology vendors. The framework requires meaningful oversight of those vendor systems, which creates a real operational challenge when vendors are not forthcoming about their internal model practices. Why This Matters Right Now The framework arrives as AI moves from internal automation into decisions that directly affect consumers: credit approvals, fraud flags, customer service responses. As these systems take on higher-stakes functions, the gap between governance-as-principle and governance-as-practice becomes a regulatory liability. What the FS AI RMF represents, beyond its specific controls, is a coordination mechanism. Treasury and the Cyber Risk Institute developed it with input from financial institutions, regulatory bodies, and standards organizations. The goal appears to be establishing a shared understanding of what adequate AI risk management looks like before formal regulation arrives and forces the conversation. For institutions that have already built robust model risk management programs, much of this is not new territory. The framework was deliberately designed to align with existing MRM practices rather than replace them. What it adds is a structured way to extend those practices to AI-specific risks that traditional model validation was not designed to catch: algorithmic fairness, adversarial robustness, foundation model dependencies. The Open Questions The framework is voluntary. That status will matter a great deal for how quickly institutions adopt it. Voluntary frameworks in financial services have a history of becoming effectively mandatory once regulators begin referencing them in examination guidance, but that process takes time and the current framework offers no guarantee of that trajectory. Vendor transparency remains an unsolved problem. The framework correctly identifies third-party AI oversight as a priority control area. It does not solve the practical reality that many vendors treat their model internals as proprietary and are not interested in producing the documentation their customers’ regulators want to see. For institutions with global operations,

When AI Code Security Tools Become Part of the Supply Chain A development team merges a pull request. The patch came from an AI security assistant. It fixed a real vulnerability and passed every test. Days later, a deeper audit turns up something strange: buried inside the fix is a subtle change to authentication logic. Nothing obviously broken. Nothing flagged during review. Just a quiet, coherent-looking alteration that slipped through because the code looked right. That scenario reflects the kind of threat model security teams now need to build around AI coding assistants. What This Is and Why It Matters Claude Code Security is an AI-driven analysis layer integrated into developer workflows and CI pipelines. It can scan full repositories, verify vulnerability findings through multiple reasoning stages, and propose patches with associated confidence scores. Results surface through dashboards, pull request comments, or automated pipeline checks. As these capabilities extend further into the development lifecycle, security teams need to account for them not simply as developer utilities, but as components with credentials, configuration surfaces, and access to sensitive code. That puts them in the same governance category as CI servers and build pipelines, and raises governance questions about how they should be managed. The Tool That Became Infrastructure The system sits alongside CI servers, build pipelines, and source repositories. It holds credentials, reads proprietary code, and proposes changes through pull request comments or suggestions. That profile is meaningfully different from earlier developer tools. Build systems and package registries occupy a similar position in the supply chain, and the security community spent years developing governance practices to account for their access and influence. AI code assistants present a similar set of considerations. How It Actually Works When Claude Code Security scans a codebase, it receives code context through API calls. It analyzes repository structure and source files, detects potential vulnerabilities, and verifies findings through multiple reasoning stages before generating recommended fixes. The underlying model is Claude Opus 4.6. By default, the tool operates in read-only mode. Write operations, command execution, and network requests all require explicit approval. File writes are constrained to the working directory. High-risk commands are blocked unless deliberately unlocked. Cloud deployments run inside isolated virtual machines. Access to services like GitHub is routed through a scoped proxy using short-lived credentials. Session logs are kept, and the VM is destroyed when the session ends. CI integrations work differently. When configured through a GitHub Action, the pipeline sends pull request diffs and contextual files directly to the Claude API. The model analyzes the changes and returns findings as comments or merge suggestions. The CI runner holds both the Anthropic API key and the repository permissions. Claude Code Security receives code through API calls but does not directly hold repository credentials. Configuration files, including .claude project settings and MCP server definitions, control which tools the assistant can call and what it is permitted to do. Where the Old Threat Model Falls Short Traditional supply chain components execute deterministic logic. A CI pipeline runs the same commands the same way every time. A package registry serves the same artifact to every caller. When they misbehave, it is usually because an attacker modified the input, not because the component reinterpreted the situation. AI assistants operate differently. They reason across context. They generate output that reflects the full content of what they were given, including documentation, comments, and instructions embedded in the codebase itself. That creates a convergence of three characteristics that previously appeared in separate components: access to sensitive data, external communication with model provider infrastructure via API, and consumption of untrusted inputs from repositories and files the assistant has no independent way to verify.Together, those three things constitute a new trust boundary in the development pipeline, one that existing threat models typically do not account for. What This Means for Enterprise Security Teams Identity and credential hygiene. API keys used in CI integrations should be treated with the same rigor as production secrets. These keys grant read access to proprietary source code and the ability to interact with live development pipelines. Compromise of the CI environment or a workflow configuration file extends to whatever the AI assistant can reach. Configuration as policy. Files that govern the assistant’s behavior, including project policies, MCP server configurations, and CI workflow definitions, function as policy code. Unauthorized modification can expand permissions, introduce malicious tool definitions, or alter what the assistant is permitted to do during automated runs. Structured review for AI-generated patches. AI-generated code changes should be clearly labeled in the pull request workflow and subject to review processes that account for their origin. Some organizations are exploring semantic diff tools and attestation-based merge policies to ensure that logic changes receive appropriate scrutiny. Supply chain inventory. These assistants belong in threat models alongside CI servers, dependency registries, and developer endpoints. That means tracking what they can access, what credentials they hold, and what configuration surfaces exist for each deployment. Risks and Open Questions API key exposure. CI workflows that integrate AI services rely on API keys stored as repository or organization secrets. Compromise of the CI environment or a misconfigured workflow definition can expose those keys to misuse. Configuration tampering. Changes to assistant configuration files or MCP server definitions can alter the tool’s available capabilities or elevate its permissions during automated runs, without triggering typical security monitoring or alerts. Prompt injection. Documentation, comments, and embedded instructions in a repository can influence the assistant’s reasoning. Content in a README or inline comment could cause the assistant to surface misleading findings or generate code suggestions that appear legitimate but are not. Patch manipulation. If an attacker introduces misleading context into a repository, the assistant may generate suggested fixes that appear correct but weaken security controls in ways that are difficult to detect during standard review. This risk emerges from combining probabilistic reasoning with review workflows designed around human-authored code. Data handling. Prompts and outputs sent to the API are subject to provider logging policies and are not encrypted

The Trace Is the Truth: Observability Is Becoming the Operational Backbone of AI Systems An enterprise chatbot fails to answer a customer query correctly. Traditional monitoring shows normal latency, no infrastructure errors, and a successful API response. From a service perspective, the system is healthy. From a business perspective, it is wrong. Extend that system into an autonomous agent that plans tasks, calls external APIs, retrieves documents, and maintains memory across sessions. The same surface metrics remain green, but the agent silently misuses a tool, retrieves the wrong document, and compounds the error across multiple steps. Without deep tracing, the organization cannot explain what happened or why. This gap defines the transition from MLOps to LLMOps to AgentOps. The Shift The evolution from MLOps to LLMOps and now to AgentOps reflects a shift in operational scope, not just terminology. As AI systems move from single-model prediction services to multi-step, tool-using agents, observability has expanded from infrastructure metrics to detailed tracing of prompts, retrieval steps, tool calls, and agent state. The pattern that has emerged across engineering teams and vendor tooling since 2024 is consistent: tracing is no longer a secondary logging feature. It is becoming the primary control surface for operating, debugging, and governing AI systems in production. How We Got Here Early MLOps focused on classical machine learning systems, typically involving training pipelines, feature stores, model versioning, and monitoring for accuracy, drift, latency, and resource consumption. Workloads were largely deterministic prediction services with stable input and output schemas. LLMOps emerged as an adaptation for large language models, introducing new operational concerns: prompt templates, retrieval-augmented generation pipelines, safety filters, token-level cost management, and conversational behavior tracking. The model was still largely a single component in a pipeline. AgentOps is the next stage. It extends LLMOps to autonomous agents that plan, reason, use tools, and maintain state across multi-step workflows — adding lifecycle management for reasoning traces, tool orchestration, guardrails, escalation paths, and auditability. At each stage, the core question has shifted. MLOps asked: did the model perform? LLMOps asked: did the prompt work? AgentOps asks: what did the agent actually do, and why? How the Mechanism Works Prompt and Application Tracing Modern LLM observability platforms treat each request as a structured trace composed of spans. A span may represent an LLM call, a retrieval step, or a tool invocation. Each trace typically captures prompt text and template version, model parameters, token usage and latency, retrieved documents and embeddings, tool descriptions and function calls, and runtime exceptions. Platforms such as Arize and Langfuse use OpenTelemetry-compatible schemas where LLM-specific events are first-class entities. Rather than relying on unstructured logs, traces encode parent-child relationships so teams can reconstruct the entire chain of execution. Because LLM outputs are non-deterministic, tracing is the primary debugging mechanism. Without it, engineers cannot reliably reproduce or explain specific conversations or agent runs. Retrieval and Tool Invocation as First-Class Signals In RAG and agent systems, retrieval quality and tool usage are common failure points. Observability frameworks now log which documents were retrieved, from which index or source, along with embedding metadata, tool call inputs and outputs, and tool-level errors. Distributed tracing across model calls, retrieval systems, and external APIs allows teams to correlate downstream failures with upstream decisions. A hallucinated answer may be traced to stale or irrelevant retrieval results. Agent State and Execution Graphs AgentOps tooling adds graph-level telemetry. In integrations such as AgentOps with LangGraph or AG2, traces include the node and edge structure of agent graphs, per-node inputs and outputs, state changes across steps, tool usage and outcomes, execution timing, and session-level metrics. This produces a replayable execution history for each agent run. Teams can inspect how a plan evolved, which tools were selected, and where reasoning drift occurred. Session-Level Observability Unlike classical APIs, AI systems are often session-based. Platforms such as Arize and Langfuse group traces into sessions, enabling analysis of user journeys across multiple interactions. This supports identification of degradation patterns that do not appear in single requests, such as cumulative reasoning drift or escalating latency across steps. Why This Gets Complicated Fast Consider a financial services agent tasked with preparing a client portfolio summary. It retrieves market data, pulls recent account activity, runs a few calculations, and drafts a report. Each step looks fine in isolation. But the market data it retrieved was cached from the previous trading day. The agent has no way to flag this. It produces a clean, confident output that an advisor sends to a client — one that understates a significant intraday move. No error was thrown. No latency spike. No failed API call. The only way to catch this is to trace exactly which document was retrieved, from which source, at what time, and how it was used downstream. This is the failure mode that traditional monitoring cannot see. And in agentic systems, it is not the exception — it is the expected shape of failure. Every prompt ID, session context, model version, and tool invocation creates new dimensions of data. Incorrect plans propagate across steps. Tools get misused or misinterpreted. Retrieval mismatches compound. Recursive loops develop. State falls out of sync in multi-agent systems. Without structured tracing, root cause analysis becomes unreliable — and in regulated industries, explaining what the agent did is not optional. Observability is therefore moving closer to a runtime control function, providing the data required to detect reasoning anomalies, tool abuse, cost spikes, and drift across long-running workflows. Implications for Enterprises Operational AI systems must emit structured traces that include prompts, retrieval results, tool calls, and state transitions. Token-level tracking and per-session cost metrics become necessary as multi-step agents multiply inference calls. Incident response now includes reasoning trace inspection, not just log review. Durable execution frameworks that separate deterministic orchestration from nondeterministic activities must integrate with observability layers to preserve state after failures. Technical Traditional metrics-first systems may discard the fidelity required for AI debugging. Teams must design storage and indexing strategies for highcardinality trace data. Non-human agent identities require cryptographically

The Evidence Problem: State AI Laws Are Asking for Documents Most Enterprises Don’t Have Colorado, Connecticut, and Maryland are turning AI governance into recurring work with deadlines, documentation requirements, and user rights obligations. The question for enterprise teams is not whether frameworks exist, but whether the evidence to satisfy them is ready. Short Scenario A product team launches an AI-assisted hiring tool. It ingests resumes, scores candidates, and flags whom to advance. The model performs well in testing. Legal clears the launch. Once the regime is in force, a compliance inquiry arrives, whether from a regulator, an internal audit, or a procurement diligence process. The request covers the impact assessment conducted before deployment, training data documentation, performance metrics, discrimination risk evaluation, vendor documentation provided to the deployer, applicant notices, and any explanation or appeal process. None of this is about whether the model worked. It is about whether governance was treated as a system requirement from the start. Several U.S. states are establishing AI governance regimes that regulate certain systems not because they are “AI,” but because they materially affect people’s rights, opportunities, or access to essential services. Colorado’s enacted Colorado AI Act SB 24 205 , Connecticut’s pending SB 2, and Maryland’s enacted AI Governance Act for state agencies represent the most developed frameworks. A parallel track is forming through California’s ADMT regulations and a separate frontier-model transparency regime under SB 53. These frameworks share a common logic: define a category of systems called “high-risk” or “high-impact,” attach governance obligations to that category, and require evidence that those obligations were met. The shared trigger is consequential decisions: those with legal or similarly significant effects in domains such as financial or lending services, housing, insurance, education, employment, healthcare, or access to essential goods and services. Colorado and Connecticut focus on private-sector developers and deployers. Maryland focuses on public-sector agencies. California spans both, depending on the provision. Key deadlines: Colorado’s core obligations take effect June 30, 2026. Connecticut’s SB 2 would take effect February 1, 2026 if enacted. Maryland’s agency inventory deadline was December 1, 2025, with impact assessments for certain existing systems due by February 1, 2027. California’s frontier-model obligations under SB 53 are effective January 1, 2026, with ADMT rules following January 1, 2027. Organizations not yet in-scope for every regime may already have suppliers, customers, or public-sector counterparts that are. How the Mechanism Works Classification: “High-Risk” and “Consequential Decisions” The governance trigger is not the presence of AI. It is the role the system plays. Colorado and Connecticut both use the framing of “high-risk AI systems” that make, or are a substantial factor in making, consequential decisions. Once a system crosses that threshold, it becomes a governed system with documented controls rather than a standard software feature. In practice, classification is harder than it appears. Many systems sit at the edges: they inform rather than decide, or they contribute to a workflow where a human nominally makes the final call. Getting classification right is the prerequisite to everything that follows. Developer Obligations vs. Deployer Obligations Both Colorado and Connecticut split responsibilities between developers (those who create or provide the AI system) and deployers (those who use it in an operational context affecting people). Developers are responsible for reasonable care, for providing deployers with the technical documentation needed to conduct assessments, and for publishing statements about high-risk systems and risk management practices. Colorado adds a notification requirement: developers must alert the Attorney General and known deployers within 90 days of discovering, or receiving a credible report, that a system has caused or is likely to cause algorithmic discrimination. Deployers carry the implementation burden: a risk management policy and program for each high-risk system, comprehensive impact assessments, annual reviews, consumer notices, and rights processes for adverse decisions. Deployers cannot complete their obligations without adequate documentation from developers. Gaps in vendor-supplied materials are a compliance blocker, not just a legal footnote. Evidence Artifacts Compliance is not a checkbox. Required artifacts typically include a risk management policy and program; a comprehensive impact assessment per highrisk AI system covering purpose, data categories, performance metrics, discrimination evaluation, and safeguards; documentation packages flowing from developers to deployers; and public statements about high-risk system categories. These artifacts must be maintained over time, not produced once at launch. Transparency and User-Facing Controls Colorado and Connecticut both require AI interaction disclosures for systems intended to interact with consumers, and consumer notice when a high-risk system is used in a consequential decision context. Both include rights to explanation, correction, and appeal or human review following adverse consequential decisions. Connecticut SB 2 adds watermarking requirements for AI-generated content under specified circumstances. These obligations require operational readiness across support, legal, and product teams, including the ability to field appeals, trace decisions, and enable meaningful human review. Public Sector Governance Maryland requires state agencies to maintain inventories of high-risk AI systems, adopt procurement and deployment policies, and conduct impact assessments on a defined schedule. California’s government inventory requirement mandates statewide visibility into high-risk automated decision systems and reporting. Framework Alignment as a Defense Colorado and Connecticut both reference the NIST AI Risk Management Framework as a basis for asserting reasonable care or an affirmative defense. This creates an incentive to build one internal governance program mapped across jurisdictions rather than separate compliance tracks per state. A Second Scenario: The Vendor Problem An enterprise deploys a third-party AI model to score commercial loan applications. The vendor provides a model card and a brief technical summary. When the deployer’s compliance team begins its impact assessment, it finds the vendor documentation does not include discrimination testing results across protected classes, does not describe training data sources with enough specificity to evaluate potential bias, and does not provide the performance metrics expected for the impact assessment. The deployer cannot complete its assessment without that information. Procurement did not require it at contract time. The compliance deadline is fixed. This is a representative failure mode implied directly by the developer-deployer split these frameworks create. Procurement processes

LLMjacking: The Credential Leak That Becomes an AI Bill A team enables Amazon Bedrock for an internal assistant in late Q3. Adoption is modest but growing. In early Q4, a developer opens a support ticket: the assistant is returning errors and occasionally timing out. The on-call engineer suspects a model quota issue and checks the Bedrock console. Quotas are nearly exhausted. She assumes a misconfigured load test and files it for the morning. The billing alert arrives two days later. Overnight spend has spiked to a level that triggers the cost anomaly threshold. By the time the investigation reaches CloudTrail, the pattern is clear: the same IAM principal has been invoking models at high volume across two regions for five days. The first invocations included a call to GetModelInvocationLoggingConfiguration and a ValidationException on an InvokeModel call with max_tokens_to_sample = -1. Neither event triggered an alert. The engineer recognizes them now for what they were: an automated tool checking whether the key had invocation rights and whether logging was configured. It did, and logging did not appear to be enabled. The abuse began shortly after. “LLMjacking” describes a practical attack pattern: adversaries steal cloud credentials or API keys, then use them to invoke managed LLM services at the victim’s expense. Reporting and vendor write-ups from 2024 through early 2026 document recurring tradecraft across providers, including reconnaissance against AI service APIs, high-volume inference abuse, and resale of hijacked access through reverse proxies. The term and pattern emerged publicly in late 2024 from an incident reporting that described stolen AWS access keys being used to abuse Bedrock and other hosted LLM services. Through 2025 and into early 2026, multiple sources treated LLMjacking as a distinct subcategory of cloud service hijacking, documenting it in mainstream industry reporting, threat detection reports, and technical incident analyses. Across these sources, the defining feature is not a novel exploit in model infrastructure. It is the reuse of familiar cloud compromise paths, followed by targeted abuse of AI service APIs that carry high variable costs and are often governed primarily by identity and quota controls. How the mechanism works LLMjacking is typically described as a lifecycle with four stages: credential acquisition, service enumeration, access verification and quota probing, then sustained abuse and monetization. 1. Credential acquisition Sources describe three common paths: 1. Exploitation of internet-facing applications to gain execution, then harvesting credentials from environment variables, configuration files, or instance metadata. Several reports highlight vulnerable Laravel deployments CVE 2021 3129) as one such foothold leading to credential theft and later LLM abuse. 2. Leakage of static cloud keys or vendor API keys in public repositories, CI/CD logs, or misconfigured pipelines, followed by automated discovery and validation by scanners. 3. Phishing, credential stuffing, or purchase of valid cloud identities from credential markets, including developer and service accounts that already hold AI permissions. 2. Enumeration of AI services and regions Once a credential is obtained, actors validate the principal and enumerate AI capabilities using standard cloud APIs. Examples cited include AWS calls such as GetCallerIdentity and Bedrock model listing calls such as ListFoundationModels and ListCustomModels, along with equivalent enumeration of Azure OpenAI and GCP Vertex AI. Region selection also appears in incident reporting. Actors probe regions that support the target AI service to maximize throughput and avoid wasted calls. 3. Stealthy access verification and logging checks A recurring technique in detailed writeups is deliberate misuse of model invocation parameters to trigger a predictable validation error. For AWS Bedrock, sources describe invoking InvokeModel with an intentionally invalid parameter value (for example, max_tokens_to_sample = -1 ) so the service returns a ValidationException. The distinction matters: a validation error indicates the principal can reach the service and has invocation rights, while AccessDenied would indicate missing permissions. Reports also describe queries to determine whether model invocation logging is enabled, including calls like GetModelInvocationLoggingConfiguration. Some tooling reportedly avoids keys where prompt and response logging is active, consistent with an attacker’s preference for minimizing visibility. 4. Sustained inference abuse and resale After confirmation, actors ramp to high-volume invocations, sometimes across multiple regions and providers. The abuse can serve two operational goals: 1. Offloading compute costs for the attacker’s own workloads, including the generation of phishing content or other malicious outputs described in several sources. 2. Reselling access by placing a reverse proxy in front of a pool of stolen keys. Multiple reports describe “OAI Reverse Proxy” or similar tooling as a way to centralize credential inventory and expose a single service endpoint to downstream customers while distributing usage across compromised accounts. What the Attacker Sees The defender experience described above spans days. The attacker’s side of the same event takes minutes and is largely automated. A scanner ingests a newly discovered key, likely pulled from a public repository commit or a credential market. It calls GetCallerIdentity to confirm the key is valid and resolves the account ID and principal. It then calls ListFoundationModels against a set of target regions to identify which AI services the principal can enumerate. Two regions return results. The tool issues an InvokeModel call with max_tokens_to_sample = -1. The service returns a ValidationException, not AccessDenied. The key has invocation rights. A call to GetModelInvocationLoggingConfiguration returns no active logging configuration. The key passes all checks. The key is added to a proxy pool. From that point, the proxy routes inference requests from downstream customers through the compromised account, distributing load across a rotating set of stolen keys. The original account holder’s quota absorbs the traffic. The attacker’s customers pay the proxy operator a fraction of retail API pricing. The account holder pays the cloud bill. No model-side exploit is required. The initial access comes from standard credential compromise paths, and the abuse uses legitimate AI service APIs. The primary impact can be cost and quota exhaustion, and some reporting also discusses follow-on goals such as data access or pivoting depending on how the service is integrated. The entire entry sequence can be executed quickly and is largely automated. Analysis Two practical shifts explain why