AI agent security governance tightens as the US sets new rules

At a glance

What this is: This is Zenity's analysis of a new US AI security blueprint that pairs voluntary federal benchmarking and pre-release review with stronger attention to AI-enabled cyber abuse.

Why it matters: It matters because AI agents inherit access to credentials, APIs, and production systems, so IAM and security teams need governance that can see and constrain runtime behaviour, not just approve model deployment.

Context

The core governance gap is that AI agents can act with inherited access inside real environments while existing oversight models still assume controls will be applied before release or after the fact. That assumption becomes fragile when the system can select actions, touch tools, and operate across production systems in ways that outpace human review cycles.

Zenity argues that the new US blueprint reflects a broader shift: AI security is no longer a future policy question, but an operational identity problem. For IAM, PAM, and NHI programmes, the issue is not only what a model can do, but what runtime access it can exercise without sufficient visibility or accountability.

Key questions

Q: What breaks when AI agents inherit the creator’s access without review?

A: Maker-identity inheritance breaks the separation between who built the agent and who should be accountable for its access. The builder’s privileges can become embedded in the artefact, then reused at runtime across systems the builder never intended. That creates hidden privilege transfer and weakens both governance and auditability.

Q: Why does malicious AI agent use matter for identity governance and compliance?

A: Because the same access layer that enables approved automation can also support illegal access, identity fraud, and wire fraud. When regulators and law enforcement start treating agent misuse as a priority, identity teams need auditable evidence of intent, delegation, and containment. Without that evidence, sanctionable behaviour is hard to distinguish from routine automation.

Q: How can organisations tell whether an AI agent is operating outside its intended boundary?

A: Look for inconsistent classifications, premature tool calls, fabricated inputs, and responses that ignore structured guardrails. Those signals show the agent is optimising for task completion rather than respecting the workflow boundary. The safest response is to tighten the schema and review the tool path, not just rewrite the prompt.

Q: How do organisations decide whether an AI agent needs NHI controls, AI controls, or both?

A: Use the identity behaviour as the deciding factor. If the system needs credentials, tokens, or delegated access to operate, NHI controls are required. If it also makes runtime decisions about tools and actions without approval gates, AI governance is also required. Many enterprise agents will sit across both control domains.

Technical breakdown

Why runtime visibility becomes the control point for AI agents

AI agents are software entities that can inherit credentials, query APIs, and execute actions across systems. The problem is not the model alone, but the access path around it: an agent with delegated authority can move from reasoning to action without the checkpoints used for human users. Traditional oversight tools often see the identity that issued the access, not the runtime decisions made after access is granted. That is why governance has to track session behaviour, tool invocation, and boundary violations in parallel. In practice, the security question shifts from whether the model is allowed to exist to whether its live behaviour stays inside an approved operating envelope.

Practical implication: Map agent runtime telemetry to the credentials and tools it can reach, so misuse is visible before it becomes a production incident.

How voluntary benchmarking changes AI governance pressure

The blueprint's voluntary benchmarking approach matters because it creates a reference point for evaluating advanced AI cyber capability without imposing a hard licensing model. For practitioners, that means frontier AI governance will likely become more evidence-based, with model behaviour assessed against cyber-relevant criteria rather than abstract policy language. This is especially relevant where agents can identify vulnerabilities, chain tool use, or interact with sensitive environments. The important architectural point is that security review now has to account for capability thresholds, not only deployment approvals. That moves AI governance closer to risk classification, where what the system can do determines how tightly it must be watched.

Practical implication: Use capability-based review to decide which AI systems need enhanced logging, tighter delegation, and restricted tool access.

Why malicious AI agent use is becoming a compliance issue

The order's enforcement language matters because it explicitly treats malicious AI agent use as a cybercrime priority. That does not create new offences, but it does signal that agent misuse will increasingly be interpreted through access abuse, fraud, and unauthorised system interaction. For identity teams, this creates a new governance boundary: an AI agent cannot be treated as a neutral automation layer when its runtime behaviour can be directed toward illegal access or fraud. The practical consequence is that policy, detection, and audit evidence all need to distinguish sanctioned agent behaviour from misuse, especially where the same underlying identity can support both.

Practical implication: Define acceptable agent behaviour, then log enough evidence to show when an AI identity crosses from approved automation into misuse.

Threat narrative

Attacker objective: To use AI-driven access and automation to gain unauthorised system access, commit fraud, or accelerate exploitation faster than human defenders can respond.

1. Entry occurs when an AI-enabled adversary or malicious agent gains legitimate or delegated access to systems, credentials, or tools used in production workflows.
2. Escalation happens when the agent uses that access to identify vulnerabilities, chain actions, or exceed the operational intent of the original delegation.
3. Impact follows when the agent or adversary uses those capabilities for illegal access, identity fraud, or automated exploitation at machine speed.

Breaches seen in the wild

• SalesBleed Salesforce Agentforce 2026: Three fixed Agentforce flaws let poisoned web leads make AI agents leak CRM data with zero clicks and send phishing under the agent's identity.
• DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Runtime visibility is now the deciding control for AI agents: once an agent can inherit credentials, call tools, and act inside production systems, pre-release review alone cannot govern the live risk. The new US blueprint reflects that shift by treating advanced capability and misuse detection as operational concerns, not just policy ones. Security teams should read this as a signal that agent governance begins where runtime behaviour becomes observable and ends where it becomes unaccountable.

Access review processes assume access persists long enough to be reviewed, but autonomous behaviour collapses that window: if an agent can acquire, use, and discard access within a short execution span, the traditional certification model has nothing stable to inspect. That is the assumption collapse this policy environment exposes. Practitioners need to rethink whether governance sits at issuance time, at runtime, or both, because post hoc review can miss the event entirely.

AI agent misuse is moving from technical concern to enforcement category: the order's focus on illegal access, identity fraud, and wire fraud shows that agent behaviour will increasingly be judged by outcome, not by whether the underlying model was approved. That is a material change for IAM, PAM, and NHI programmes because the same identity substrate can support sanctioned automation or criminal misuse. Practitioners should treat provenance, delegation, and auditability as legal as well as operational controls.

Ephemeral privilege without behavioural evidence creates an identity blind spot: a system can be formally authorised and still function outside its intended boundary if no one can show what it did with that access. The article's emphasis on visibility makes this more than a logging problem; it is a governance problem about proving intent, scope, and containment. The implication is that AI identity governance must be built to explain actions, not merely grant access.

AI agent governance will increasingly converge with NHI governance, but not collapse into it: the access substrate is similar, yet the risk profile changes when the identity can choose actions at runtime. That means NHI controls remain necessary but insufficient on their own. Practitioners should expect AI-specific governance to layer on top of existing identity controls rather than replace them, especially where high-capability models can interact with sensitive systems.

From our research library:

• Only 23% of IT leaders were very confident in their organisation's ability to manage security and governance for GenAI deployments, according to a 2025 Gartner survey of 360 IT leaders.

What this signals

Agent governance now sits between IAM and cyber operations: the practical gap is no longer just who holds the credential, but what the agent does after it receives it. Programmes that treat AI systems like ordinary service accounts will miss the behaviour layer, where misuse, scope drift, and tool chaining actually occur.

Runtime accountability is the new governance primitive: the article points toward a world where policy needs to prove what an agent did, not simply that it was authorised. That will push security teams toward richer audit evidence, tighter delegation design, and controls that can survive machine-speed decision cycles.

For practitioners

• Define AI agent runtime boundaries Document which tools, datasets, and production systems an agent may touch, then treat any action outside that envelope as a governance exception, not a tuning issue.
• Instrument delegated access paths Log which identity issued the access, what the agent invoked, and which actions occurred during the session so you can reconstruct misuse and scope drift.
• Separate sanctioned automation from misuse Create policy and detection rules that distinguish approved task execution from identity fraud, unauthorised access, or illegal tool use by the same agent identity.
• Review pre-release and runtime controls together Do not treat pre-release evaluation as a substitute for live monitoring, because the article's core risk is behaviour that only emerges after deployment.

Key takeaways

• The article frames AI agent security as a live governance problem, not a future policy debate, because agents can inherit and use access inside real production environments.
• The strongest practical signal is the need for runtime visibility over delegated access, tool use, and behaviour boundaries, not just pre-release review.
• For practitioners, the key control shift is from static approval to evidence-based accountability that can distinguish sanctioned automation from misuse.

Key terms

• Agent Runtime: The agent runtime is the execution environment where an AI agent reads data, calls tools, and carries out actions. It matters because the runtime is where identity, policy, and filesystem boundaries either hold or fail. If those boundaries are weak, the agent becomes a high-privilege path into the environment.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
• Scope drift: Scope drift is the gradual mismatch between what an integration was meant to do and what its credentials still allow it to do. It happens when permissions are not revalidated as business needs change, creating hidden over-privilege across SaaS and API-connected systems.
• Misuse Detection: Misuse detection is the identification of sanctioned identities, tools, or workflows being used for unauthorised or harmful purposes. For AI agents, it must evaluate behaviour, not just access rights, because the same access path can support both legitimate tasks and criminal activity.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.