TL;DR: AI agents can interpret objectives, invoke applications, access sensitive data, and initiate transactions with limited intervention, which expands the identity, data, and operational attack surface, according to Living Security Human Risk Management Platform. The control problem is not universal approval gates but attributable, bounded, observable, and reversible authority, because AI agent identity governance now has to cover delegated action, runtime context, and human accountability at once.
At a glance
What this is: This is an analysis of how enterprises can govern AI agents so they keep their autonomy benefits without creating untracked access, uncontrolled actions, or weak accountability.
Why it matters: It matters because IAM, PAM, and identity governance teams now have to manage machine identity, delegated authority, and runtime controls together rather than treating agents like ordinary automation.
Context
AI agents change the enterprise risk model because they combine machine identities, delegated authority, application access, and probabilistic reasoning in one operating layer. The governance problem is not simply access control, but how to keep that access attributable and bounded when the agent can revise its plan at runtime.
For identity and governance teams, the key issue is that an agent may interpret an objective, choose which applications to invoke, and act on new information without following a fixed script. That makes human approval alone too slow and too late if the surrounding controls are not enforcing scope, evidence, and rollback.
The article frames this as a Human Risk Management problem as much as an AI governance problem. The right control model ties the agent to ownership, telemetry, and escalation boundaries so the enterprise can support adoption without losing control of consequential actions.
Key questions
Q: How should regulated industries implement AI agent security without blocking adoption?
A: Regulated industries should treat compliance as an implementation constraint, not a reason to ban AI agents. The right approach is to map existing obligations to the agent workflow, then enforce scoped access, immutable audit logging, and source validation. That lets healthcare, finance, insurance, and government teams control risk while still using agents for bounded business tasks.
Q: Why do AI agents need distinct machine identities in production?
A: Distinct machine identities let teams bind every agent action to a known runtime actor with a defined scope. Without that separation, shared service accounts blur accountability, make revocation difficult, and hide whether an action came from the intended agent or from another automated workflow.
Q: What are the signs that AI governance is failing in the enterprise?
A: Common warning signs include rapid growth in AI use without matching policy coverage, sensitive files being copied into personal accounts, and a large share of AI apps carrying high or critical risk. Another indicator is weak visibility into who is using which tools and what data they are sending. If teams cannot answer those questions, governance is not working as intended.
Q: What should organisations do when an agent is allowed to make consequential decisions?
A: Use risk-adaptive approval. Let the agent handle reversible, low-impact work automatically, but require human review for actions that affect sensitive data, privileged systems, legal commitments, or major financial value. The approval record should capture reason, scope, evidence, and rollback method.
Technical breakdown
Why AI agents behave differently from conventional automation
Conventional automation follows predefined logic, so its access pattern is predictable at design time. AI agents are different because they can interpret a broad objective, select a sequence of actions, and revise that plan after receiving new information. That means security controls have to account for runtime decision-making, not just initial configuration. A poisoned prompt, excessive entitlement, exposed credential, or compromised retrieval source can influence an entire action chain. The governance question is therefore not whether the model is smart enough, but whether the surrounding identity, access, and execution controls are precise enough to contain its choices.
Practical implication: control the agent’s runtime authority outside the model, not just its instructions.
Distinct machine identity and short-lived credentials for agents
An AI agent should not inherit a user’s session or operate under a generic shared account. It needs a distinct machine identity tied to an owner, an approved purpose, and an expiration point so access can be reviewed and revoked cleanly. Short-lived credentials, scoped tokens, and workload identity federation reduce the value of any compromise and keep permissions aligned to the approved task. Static secrets in prompts, logs, or memory stores create a durable exposure path that does not fit the way agents actually operate. The mechanism matters because agent authority is only governable when the credential lifecycle is explicit.
Practical implication: issue each production agent its own identity and bound credentials.
Execution boundaries are stronger than prompt instructions
Prompt text can guide behaviour, but it is not a security boundary. Real control has to sit in gateways, policy engines, target applications, and approval workflows that can block disallowed actions even if the model proposes them. That is why the article emphasises allowlists, transaction limits, row-level permissions, egress filtering, and validation at the point of execution. These controls constrain what the agent can do with a valid credential, which is where most consequential failures occur. In practice, the objective is to prevent a single unsafe instruction from becoming unrestricted enterprise access.
Practical implication: enforce capability controls where the action happens, not where the prompt is written.
Threat narrative
Attacker objective: The attacker aims to convert an agent’s delegated authority into unauthorized enterprise actions, data exposure, or operational damage with limited resistance.
- Entry occurs when an AI agent is given delegated access to enterprise applications and data through a machine identity or inherited workflow permissions.
- Credential access or misuse follows when excessive permissions, exposed credentials, or poisoned inputs let the agent act beyond the intended scope.
- Impact occurs when the agent initiates transactions, changes records, or triggers downstream actions that are hard to attribute, contain, or reverse.
Breaches seen in the wild
- postmark-mcp malicious MCP server 2025: A fake Postmark MCP server on npm quietly BCC'd every email AI agents sent through it to an attacker, using victims' own Postmark tokens.
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
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
AI agent governance fails when enterprises treat runtime authority like static access. The article shows that agents do not just consume permissions, they can sequence actions, revisit plans, and invoke connected applications as conditions change. That breaks governance models built for fixed workflows and makes the unit of control the complete human-agent workflow, not the model in isolation. Practitioners should treat the governing problem as attributable runtime authority, not simple approval management.
Distinct identity is the control anchor for agent accountability. An agent that inherits a user session or hides behind a shared service account collapses attribution before the first consequential action occurs. Unique machine identity, explicit ownership, and revocation boundaries are what make incident reconstruction and exception management possible. This is why AI agent identity is now a governance discipline, not a naming convention.
Prompt security is not a substitute for execution control. The article is correct to shift focus from instructions to enforceable boundaries because unsafe outcomes happen when valid credentials meet excessive capability. That means the relevant governance gap is not just model misuse, but permission design that assumes a prompt can safely contain behaviour. The practitioners who will manage this well are the ones who bind capability, data scope, and transaction value at the control plane.
Human-led oversight remains necessary, but only at the point of material consequence. Universal approval gates slow adoption and still miss fast-moving agent abuse. Risk-adaptive oversight is the more durable pattern because it reserves human judgment for sensitive, irreversible, or regulated actions while allowing bounded autonomy for low-impact work. The implication is that identity programmes must distinguish reversible execution from consequential execution, then govern each differently.
Bounded autonomy is the named concept that best captures this control model. The article describes a posture where agents can act without constant intervention, but only inside explicit limits that preserve attribution, observability, and rollback. That concept is more useful than a generic zero-trust label because it captures the actual enterprise problem: autonomy is acceptable only when it remains technically bounded. Practitioners should design for bounded autonomy, not universal approval.
From our research library:
- 54% of organisations are actively deploying AI agents across workflows, yet only 21% report a mature governance model for agentic AI.
- Read next: Agentic AI Identity Guide
What this signals
Bounded autonomy changes the governance unit. Security teams should stop treating the model as the boundary and start governing the complete human-agent workflow, because the risk is created by delegated action plus runtime access. That shift affects ownership, evidence collection, and escalation design across IAM and SOC operations.
Access review alone is too late for agentic systems. Once an agent can request, use, and discard access within one workflow, classic recertification windows lose most of their value. The control point moves to issuance, capability enforcement, and rollback readiness, which is why programme design has to change before adoption accelerates further.
AI agents are moving into production faster than governance maturity. 54% of organisations are actively deploying AI agents across workflows, yet only 21% report a mature governance model for agentic AI, according to the 2026 Infrastructure Identity Survey. That gap suggests the next year will be defined less by agent rollout and more by control standardisation.
For practitioners
- Inventory every production agent Record owner, purpose, model, connected applications, data classes, credentials, and deployment status so unregistered agents cannot operate outside governance.
- Issue a distinct machine identity Bind each agent to its own identity, approved scope, and expiration date instead of letting it inherit a user session or shared service account.
- Move controls to the execution layer Enforce allowlists, transaction limits, validation, and egress filtering in gateways and target systems so prompt text is not treated as a control boundary.
- Separate approval from execution for high-impact actions Require human review for irreversible or regulated actions and log the initiating user, agent identity, sources, invoked interfaces, and rollback status.
Key takeaways
- AI agents widen the attack surface because they combine delegated authority, application access, and runtime decision-making in one control problem.
- The governance failure is not simply lack of approval, but lack of attributable, bounded, observable, and reversible authority.
- Distinct identities, execution-layer controls, and risk-adaptive oversight are the controls that make adoption workable.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centres on distinct agent identities, short-lived credentials, and runtime access binding. |
| NHI-05 — Overprivileged NHI | The article warns that excessive permissions let agents turn one unsafe action into broad enterprise access. | |
| NHI-07 — Long-Lived Secrets | The article explicitly rejects static secrets in prompts, code, memory stores, and logs. | |
| Recommendation — Issue each agent a distinct identity and short-lived credentials instead of inheriting user access. Scope agent permissions to the minimum application, action, resource, and time window required. Replace static agent secrets with short-lived runtime credentials and revoke exposed tokens immediately. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article focuses on runtime abuse when an agent can misuse delegated authority and connected applications. |
| Recommendation — Constrain agent privilege so runtime decisions cannot exceed the approved action envelope. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about governing entitlements, approvals, and revocation for AI agents. |
| Recommendation — Review and enforce agent entitlements so every consequential action remains explicitly authorised. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article discusses exposed credentials and chained application access as the path to impact. |
| Recommendation — Map agent credential exposure and downstream access movement to TA0006 and TA0008 in threat analysis. | ||
Key terms
- Bounded Autonomy: Bounded autonomy means a system can act independently within defined limits, but cannot exceed those limits without human or policy control. In agentic governance, the boundary must be explicit, testable, and logged, because the real compliance question is where autonomous action stops.
- Agent Identity: An agent identity is the set of attributes, credentials and permissions assigned to an autonomous software entity. It is treated as a non-human identity because it can authenticate, act on systems and accumulate access over time, which creates governance, audit and lifecycle obligations similar to other production identities.
- Risk-Adaptive Oversight: A control approach that applies different approval requirements based on the potential impact of an AI agent’s action. Low-impact, reversible tasks can proceed automatically, while sensitive or irreversible decisions require human review, preserving speed without abandoning accountability.
- Execution boundary: The point at which an authorised task turns into a real system change, such as writing data, deleting records, spending money, or invoking a downstream tool. In AI governance, controlling the execution boundary matters more than simply approving access, because harm occurs when actions are allowed to complete unchecked.
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 IAM programme, it is worth exploring.
Published by the NHIMG editorial team on August 20, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org