TL;DR: Enterprise AI agents can retrieve files, call APIs, execute code and act through service accounts, OAuth tokens or cloud roles, so model guardrails alone cannot stop authorised destructive actions, according to Jamf. The security boundary has to move outside the model, where authority containment, execution containment and recovery controls govern what the agent can actually do.
At a glance
What this is: This is a control-plane analysis of enterprise AI agents, with the key finding that model guardrails do not stop valid credentials from being used to perform legitimate but harmful actions.
Why it matters: It matters because IAM, PAM and NHI programmes must govern the agent’s full delegation chain, not just the model’s outputs, or legitimate access becomes the attack path.
Context
Enterprise AI agents are not just chat interfaces with better workflow reach. Once an agent can use approved identities, tokens, cloud roles or tool integrations, the governance problem shifts from output quality to authority control, because the organisation has intentionally given the system a path into real systems.
The first security mistake is to treat the model as the boundary. A model may refuse a prompt, but it does not revoke a credential, constrain an API call or stop an approved action from landing in a production system.
For AI agent authorisation to work, teams have to map the full identity and delegation chain, including the ways an agent can borrow, chain or switch identities during one workflow.
Key questions
Q: What breaks when AI agents are given broad standing access?
A: Broad standing access breaks governance because the agent can move from one task to another without a fresh authorization check. That creates a control gap between intended scope and actual runtime behaviour. The result is weak accountability, limited containment, and audit trails that show activity without explaining why the activity was allowed.
Q: Why do AI agents increase security risk even when they are not compromised?
A: Because risk comes from legitimate execution, not only from malicious takeover. An agent with valid credentials can retrieve files, invoke APIs, modify repositories or trigger workflows at machine speed. If its authority is too broad, the environment has effectively granted a powerful software principal permission to act beyond the original business intent.
Q: How do security teams spot over-privileged AI agents in practice?
A: Look for agents that routinely cross system boundaries, reuse the same credential across unrelated tasks, or access more data sources than the original workflow requires. Those patterns show that the entitlement scope has drifted beyond the intended use case and is no longer defensible in review.
Q: What should organisations do before letting AI agents act on business data?
A: Organisations should verify that the agent receives governed context, not just raw data or local metadata. That includes definition provenance, policy inheritance, and usage conditions. If those elements are unclear, the agent should be constrained to assistive use rather than autonomous execution.
Technical breakdown
Why model guardrails stop at the prompt layer
Model guardrails shape generated text, but they do not control enterprise authorisation. An agent can still use an authorised token, call a permitted API, or trigger a workflow if the surrounding systems accept the request. That is why prompt filtering is a content control, not an access control. In practice, the security boundary must sit where the operation is executed: in the policy engine, credential broker, tool gateway, and destination service. If those layers do not validate the action, a safe-sounding prompt can still lead to a dangerous outcome. Read Zero Trust for AI Agents.
Practical implication: Treat prompt controls as advisory and move enforcement to the systems that authorise and execute agent actions.
Why the agent should be treated as a software principal
An enterprise agent behaves like a software principal because it has identity, permissions, tools, data sources and an execution context. Unlike a conventional service, it may also interpret natural language, choose tools at runtime, and chain actions across several systems. That combination means identity is only one part of the boundary. Governance has to include what the agent can see, what it can call, whether it can write state, and whether it can delegate to other agents or external services. Without that model, organisations undercount the real blast radius of a single agent workflow. See the Agentic AI Identity Guide.
Practical implication: Inventory each agent as an identity-bearing principal with explicit authority, dependencies and downstream reach.
How execution containment differs from authority containment
Execution containment limits where agent-controlled code can run. Authority containment limits what the agent can do through valid enterprise interfaces. A sandbox, microVM or restricted container can stop filesystem abuse or kernel escape, but it does not stop a valid credential from deleting a remote database if the credential is authorised for that action. The two controls solve different problems and must be layered. Execution containment protects the runtime; authority containment protects the legitimate path into systems and data. One without the other leaves a gap that an agent can exploit without ever breaking out of its environment.
Practical implication: Pair sandboxing with explicit action-level policy, because runtime isolation does not constrain legitimate API authority.
Threat narrative
Attacker objective: The objective is to turn legitimate agent authority into a high-speed path to data exposure, system modification or service disruption.
- Entry occurs when an enterprise grants the agent legitimate access through a service account, OAuth application, cloud role or embedded credential.
- Escalation occurs when the agent chains tools, retries failed actions, or switches identities during the same workflow to reach broader authority than the original request implied.
- Impact occurs when the authorised operation lands in a production system, moves data, changes code or triggers destructive side effects without a human decision at the point of execution.
Breaches seen in the wild
- 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 access review assumes the identity is the control boundary. That assumption works for stable accounts, but it breaks when the actor can select tools, chain actions and switch identities inside one workflow. The implication is that IAM teams must stop treating the model as the subject of review and start governing the full delegation chain.
Authority containment is the decisive control plane for enterprise AI. A sandbox can constrain code execution, but it cannot invalidate a valid token or veto an authorised API call. That is why agentic risk is structurally different from ordinary application risk: the dangerous path often uses approved access, not compromised access.
Ephemeral credential trust debt: organisations that give agents broad credentials now incur risk that is hidden until the first high-speed action chain executes. The security programme becomes responsible for authority that may be distributed across service accounts, OAuth apps and cloud roles, so the governance unit has to be the complete agent workflow, not the prompt.
OWASP Agentic AI and OWASP NHI now describe the same control problem from two angles. The agentic view explains excessive autonomy and tool misuse, while the NHI view explains overprivileged identities, secret handling and lifecycle failure. Practitioners should use both lenses together, because an agent that can act through an NHI inherits the weaknesses of both domains.
From our research library:
- 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
- Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.
- Read next: AI Agent Authorisation Guide
What this signals
Governance programmes need to stop measuring AI agents only by model behaviour and start measuring them by delegated authority. If an agent can chain identities, tools and actions inside one workflow, the risk is determined by the authority path, not the quality of its output.
Ephemeral credential trust debt: every additional token, role or OAuth grant given to an agent becomes hidden risk until the first high-speed action chain exposes it. That means agent oversight has to move upstream to issuance time, not wait for a review cycle after deployment.
Least-privilege design for AI agents is already a measurable control, not a theoretical one. 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, which explains why authority containment has become the practical control plane for agent governance.
For practitioners
- Map the full delegation chain Document every identity, credential, tool, data source, network path and approval step an agent can use, including identity switching inside a single workflow. See the Agentic AI Identity Guide.
- Separate execution control from authorisation control Use sandboxing, read-only filesystems and ephemeral runtimes for code safety, but enforce action-level policy at the tool, API and credential layers.
- Scope agent access by task and environment Grant the minimum production reach needed for the task, and keep development, test and production credentials and networks separate.
- Log the context layer and the enforcement points Capture agent intent, policy decisions, credential broker events, tool calls and destination actions so you can attribute behaviour after a failure.
- Test for delegated-action abuse before launch Exercise prompt injection, tool chaining, credential misuse and delegated-write scenarios against the deployed system, not just the model.
Key takeaways
- AI agents create a governance problem that model guardrails cannot solve on their own because legitimate credentials can still be used to perform harmful actions.
- The article frames agent authority as a layered control issue across identity, execution, policy enforcement and recovery, not a single prompt-safety issue.
- Practitioners should govern the full delegation chain, scope access by task and environment, and verify that enforcement happens outside the model.
Related NHI Mgmt Group resources: AI Agent Authorisation Guide · Agentic AI Identity Guide · Zero Trust for AI Agents · AI Agent Observability, Audit and Incident Response Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article centres on agents using legitimate identity and privilege paths to act in ways the business did not intend. |
| Recommendation — Constrain agent identity and privilege so tool use cannot exceed the approved task boundary. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Enterprise agents often operate through service accounts, OAuth apps and cloud roles that can be over-scoped. |
| NHI-04 — Insecure Authentication | The article discusses agent authentication through tokens, roles and delegated identities that need strong verification. | |
| Recommendation — Scope every agent credential to the minimum task, environment and destination access it truly needs. Verify how agents authenticate to tools and services before allowing any production authority. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article repeatedly focuses on token, credential and OAuth handling across the agent delegation chain. |
| Recommendation — Manage agent authenticators with explicit issuance, rotation, revocation and retirement rules. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The core issue is whether agent entitlements match the business task and intended authority path. |
| Recommendation — Review agent entitlements so permissions and authorisations match the minimum needed for the task. | ||
| NIST Zero Trust (SP 800-207) | Continuous Verification — Continuous Verification | The article argues that trust must be re-evaluated outside the model at the point of action, not assumed once at login. |
| Recommendation — Apply continuous verification at each agent action instead of trusting a one-time login decision. | ||
Key terms
- Agentic AI control plane: A governance layer that applies policy, audit, and access decisions across AI interactions and connected tools. It treats the AI workflow as a managed operational path, not just a model endpoint, so identity, data, and behaviour can be controlled together.
- Authority containment: Controls that limit what an AI agent may do through legitimate enterprise interfaces, including tools, APIs, credentials and delegated permissions. It is distinct from runtime containment because it constrains approved access paths rather than the code execution environment.
- Software principal: A software entity that holds identity, permissions, tools and operational purpose, and can therefore be governed like a principal rather than a mere interface. For AI agents, this framing highlights that identity alone is not enough to understand the security boundary.
- Delegation Chain: A delegation chain is the sequence of identities, credentials, and tool calls an agent uses to complete a task across systems. It matters because each step may appear acceptable on its own while the combined path produces an outcome no reviewer would have approved directly.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity security 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 October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org