TL;DR: Enterprises should give each AI agent a unique identity, preserve the human or workload behind the request, authorize named tools through external policy, and record every decision in an audit trail so least privilege and revocation remain workable at scale, according to KeyRunner. Authentication alone is not enough when execution, tool choice, and downstream credentials must be governed together.
At a glance
What this is: This is an analysis of AI agent identity and authorization design, arguing that shared identities break attribution, least privilege, and revocation even when the agent is authenticated.
Why it matters: It matters because IAM teams now need to govern AI agents as distinct principals, not just extend human-style access control to software that can choose tools and act at runtime.
Context
AI agent identity is the control problem here, not the model itself. When an agent acts through a shared service account or a borrowed human credential, the enterprise loses the ability to prove who initiated the request, which policy applied, and whether the action matched the original purpose.
The governance gap widens when teams treat authentication as the finish line. A verified agent can still be over-permissioned, steered toward the wrong tool, or allowed to reach downstream systems without a policy decision at execution time. The right framing is least privilege for AI agents applied to a distinct principal, not a proxy for the user.
Key questions
Q: How should organizations approach the governance of AI agents?
A: Organizations should adopt a governance framework that incorporates continuous visibility, adaptive IAM practices, and stringent policy-based controls. This ensures that all agent actions are tracked, authorized appropriately, and assessed for compliance.
Q: Why is authentication alone not enough for agentic AI access control?
A: Authentication answers whether the agent can prove its identity, but agentic AI can still take actions that exceed the original intent of that identity. The risk appears after login, when tool use, delegation, and chained actions expand the effective permission boundary. That is why authorisation must operate continuously, not only at issuance.
Q: What breaks when an AI agent shares one credential across tools and model calls?
A: The boundary between inference and action breaks down. A single credential can then authorise model calls, function calls, and downstream API access in the same session, which makes it hard to audit intent, limit scope, or contain misuse when the agent behaves unexpectedly.
Q: Should enterprises use the same identity for an AI agent and its human user?
A: No. The agent and the user should remain distinct identities linked in the same execution context. That separation preserves who initiated the task while allowing the agent to carry narrower permissions, independent policy, and a lifecycle that can be revoked without changing the human account.
Technical breakdown
Why shared identities break agent governance
Shared identities collapse attribution because one credential can represent many different requests, owners, and risk contexts. In practice, the security team sees an API call but cannot tell which agent requested it, which person or workload initiated it, or which policy allowed it. That destroys the evidence chain needed for access review, incident response, and revocation. Unique agent identity separates the actor from the initiator and makes policy decisions auditable at the point of execution. See the Agentic AI Identity Guide.
Practical implication: Give each agent a separate identity and register ownership, scope, and lifecycle as independent records.
Why authentication is not enough for AI agents
Authentication proves an agent is real. It does not prove the agent should perform the requested action with the given parameters, against that target, at that moment. That gap matters because agent security is decided at runtime, where the request context includes the initiator, tool, environment, approval state, and downstream credential use. External policy must sit between authentication and execution so the system can deny unsafe requests before any API call occurs.
Practical implication: Place authorization checks before tool execution and evaluate request context, not just agent identity.
How runtime credential retrieval changes the trust boundary
When credentials are retrieved only after policy approval inside a trusted runtime, the agent never needs to hold the downstream secret in its own context. That matters because the agent can then request, but not inherit, the authority required to call a tool or target system. The trust boundary shifts from static credential possession to time-bound, policy-backed execution. This reduces exposure, preserves delegation, and keeps access revocable without rotating every related principal. Read Zero Trust for AI Agents.
Practical implication: Keep downstream credentials outside the agent context and release them only after the policy decision is made.
Breaches seen in the wild
- Trivy supply chain attack 2026: A PAT stolen via a Trivy workflow and a botched rotation let TeamPCP poison Trivy releases and Action tags to steal CI/CD secrets.
- 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
Unique agent identity is the governance primitive that makes delegation legible. If one agent can stand in for many users, tasks, or workloads, then identity becomes ambiguous and accountability degrades with every shared credential. The article correctly separates the agent from the initiator, which is the only way to preserve ownership, scope, and revocation as distinct governance events. The practitioner takeaway is to treat each agent as an independently managed principal, not as a convenience wrapper around human access.
External policy at execution time is the control that keeps AI agents inside bounds. Authentication cannot decide whether a requested tool, parameter set, target, or environment is appropriate. That decision has to be made when the action is about to happen, because the risk exists in the request context, not just the login event. This is where zero trust for AI agents becomes operational rather than rhetorical: verify the agent, the initiator, and the request before any privileged action is allowed.
Human to agent to tool attribution is now a first-class audit requirement. Enterprises cannot govern what they cannot reconstruct, and reconstruction fails when the agent, initiator, policy version, and downstream outcome are logged separately or not at all. The article’s strongest point is that auditability is not a reporting layer added later. It is the condition that makes revocation, incident response, and ownership transfer work in the first place. Security teams should design for traceable execution chains, not isolated logs.
Least privilege for agents depends on curating the tool set, not just limiting tokens. The article shows that exposing the full enterprise tool catalog creates excess reach even if each tool call is individually checked. The named concept here is tool-set authority leakage: the agent can discover or request more capability than its role actually needs, which expands the blast radius of a single compromise or prompt manipulation. Practitioners should align the agent’s discoverable tools, approval path, and downstream authority to one narrow role boundary.
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.
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
- Read next: AI Agent Authorisation Guide
What this signals
Access review models assume a privilege remains stable long enough to be observed and recertified. AI agents that request a tool, execute it, and release the credential inside one workflow shorten that window so much that governance has to move to issuance and policy enforcement before execution.
Tool-set authority leakage: The practical risk is not only overbroad authentication, but overbroad discovery. When an agent can see or request more tools than its role requires, the enterprise creates a wider blast radius than the business task justifies, which weakens revocation and complicates audit evidence.
The gap is already visible in practice: 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
For practitioners
- Define a unique identity for each agent Register every agent as a separate principal with its own owner, purpose, lifecycle state, and access scope so revocation does not depend on a shared account.
- Preserve the initiating identity Carry the verified human or workload that requested the action through the full execution chain so audit, approval, and accountability stay tied to the original requester.
- Enforce policy before execution Check the agent, initiator, tool, parameters, target, environment, time, and approval state before any downstream API call is allowed.
- Keep downstream credentials outside the agent context Retrieve the credential only after the policy decision inside a trusted runtime so the agent can request access without holding the secret itself.
- Log the full attribution chain Record the initiator, agent, policy version, requested tool, decision, credential reference, approval state, and final outcome as one traceable event. See the AI Agent Observability, Audit and Incident Response Guide.
Key takeaways
- AI agents need separate identities and named policies because shared credentials erase attribution and make revocation imprecise.
- Authentication alone does not make an agent safe, because the real control point is the runtime decision to allow a specific tool, target, and context.
- Auditability has to be built into the execution chain, or security teams will not be able to prove who acted, why it was allowed, or what changed.
Related NHI Mgmt Group resources: Zero Trust for AI Agents · AI Agent Observability, Audit and Incident Response Guide · AI Agent Authorisation Guide · Agentic AI Identity Guide
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 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The article centres on AI agents receiving broader access than their task requires. |
| NHI-10 — Human Use of NHI | The article preserves the human or workload behind each agent request for accountability. | |
| Recommendation — Apply NHI-05 to narrow each agent's access to the minimum tools and actions needed for its role. Track the initiating human or workload separately from the agent and bind both to the same execution record. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article addresses runtime authorization and delegated authority for agents acting on requests. |
| Recommendation — Enforce policy checks before execution so agent identity cannot be used to justify excess privilege. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article depends on controlled credential issuance and revocation for agent execution. |
| Recommendation — Use IA-5 to manage agent authenticators and revoke credentials without disrupting unrelated principals. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about governing agent permissions and approval at the moment of access. |
| Recommendation — Apply PR.AA-05 so entitlements are authorised per request rather than assumed from the agent's identity. | ||
Key terms
- AI Agent Identity: The digital identity used by an autonomous AI agent to authenticate to external systems, APIs, and services. Managing AI agent identities is an emerging and rapidly evolving area of NHI security.
- Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
- Attribution Chain: The sequence that links an action back to the human principal, policy decision, proxy, and backend service that allowed it. In autonomous environments, preserving the attribution chain is essential for auditability, incident response, and governance.
- Tool-Set Authority Leakage: A governance failure where an agent can discover or request more tools than its role requires, even if individual tool calls are separately controlled. The issue widens attack surface and weakens least privilege because reach is expanded before the actual execution decision is made.
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 October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org