TL;DR: AI agent deployments should each have a distinct directory identity, named owner, narrow purpose, and short-lived credentials, according to Identra.ai, with controls such as allowlists, egress policy, sandboxing, approval gates, and behavioural baselining used to constrain and detect misuse. The central assumption is that agents cannot be governed safely through borrowed accounts or broad, static privilege.
At a glance
What this is: This is a practical guide to governing AI agent identities, with the central finding that agents need distinct identities, narrow delegation, and runtime controls rather than borrowed human or shared service accounts.
Why it matters: It matters because IAM, PAM, and NHI teams now have to control agent authority as it is exercised, not just at provisioning time, or runtime misuse will outpace review and revocation.
Context
AI agent identity is the governance problem created when a software system can act on behalf of a user or workload with its own runtime decisions and tool use. The control question is no longer only who signed in, but what authority the agent can exercise at each hop, how it is constrained, and whether its actions remain attributable in logs.
The article argues that agents should not borrow human accounts or shared service accounts because those patterns erase ownership, widen privilege silently, and make revocation unsafe. In identity governance terms, that makes agent identity a lifecycle problem as much as an authentication problem: onboarding, scope changes, recertification, and offboarding all have to work for the agent as a first-class identity object.
Key questions
Q: How should security teams handle agent identity when each deployment can act independently?
A: Treat each independently permissioned deployment as a first-class identity with its own owner, purpose, environment, and credential set. That keeps audit trails clean, makes revocation safe, and prevents one agent from inheriting the accumulated access of another workload or a human account.
Q: Why do borrowed human accounts make AI agents harder to govern?
A: Borrowed accounts erase attribution, widen privilege beyond the task, and make revocation unsafe because disabling the agent can also disable the person. They also hide the agent's true operating scope, which turns incident response into guesswork rather than containment.
Q: What breaks when token exchange is not narrowed at each hop?
A: The delegation chain widens silently, so a token minted for one action or server can be reused across tools and downstream APIs. That creates scope drift, weakens least privilege, and makes it harder to prove that the agent stayed inside its intended authority boundary.
Q: How do teams know if runtime controls are actually working?
A: They should be able to trace a decision from source event to applied rule to final outcome without gaps. If that lineage is incomplete, the control may look correct in reports while failing in practice. Real governance shows up in explainable timing, not just in end-of-period summaries.
Technical breakdown
Why borrowed accounts fail for agent identity
Borrowed accounts collapse the distinction between human and machine action. If an agent runs under a developer account, logs cannot cleanly separate actor intent, revocation affects the person as well as the agent, and every entitlement already attached to the human becomes available to the agent. Shared service accounts are only slightly better, because they pool many workloads behind one credential and destroy ownership. The real technical issue is attribution plus blast radius: once multiple actors share one identity, incident response cannot tell what the agent actually did, and privilege grows faster than governance can track it.
Practical implication: give each independently permissioned agent its own identity and retire borrowed accounts from production paths.
How token exchange and MCP delegation narrow authority
Delegation has to narrow at each hop. OAuth token exchange can carry authority from user to agent to downstream API, but only if the profile is strict: one audience per token, no token passthrough, and downscoping at every exchange. MCP adds another layer because tool calls are structured requests that can forward credentials unless the server is forced to act as a bounded resource server. Without that discipline, a token intended for one server can wander across tools and get reused where it was never meant to apply. The control failure is scope drift across the chain, not just weak authentication.
Practical implication: bind each hop to a single audience and block token forwarding across MCP servers and downstream APIs.
Why deterministic controls must precede behavioural baselines
Behavioural baselining is useful, but it cannot replace preventive controls. Deterministic restrictions such as allowlists, egress policy, sandboxing, and approval gates reduce the space in which an agent can act before execution begins. Baselines then watch for misuse inside that allowed envelope, especially when an agent behaves plausibly while still being harmful. This sequencing matters because an agent can remain within policy and still be dangerous if the policy itself is too broad. Runtime monitoring without narrow authorization only tells you that the wrong thing happened inside an over-permitted boundary.
Practical implication: set hard runtime boundaries first, then use behavioural detection to catch misuse inside those boundaries.
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.
- Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
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 identity is a governance object, not just an authentication object: the article is right to separate deployment identity, execution identity, and requesting human context. That separation matters because the governance question changes at each layer: who owns the deployment, what the session can do, and which downstream systems receive delegated authority. Practitioners should treat agents as first-class identities with lifecycle, review, and revocation requirements, not as anonymous automation wrapped in a login.
Borrowed accounts create identity blast radius: the decision to run agents under human or shared service accounts breaks attribution, revocation, and least privilege at the same time. This is not a minor policy shortcut; it is a structural failure of identity design because the agent inherits all accumulated human access and any future misuse becomes indistinguishable from legitimate user behaviour. The practical consequence is that auditability and containment both degrade as soon as a shared credential enters the chain.
Narrow delegation must be enforced hop by hop: authority should never widen as an agent moves from a user request to a tool call to a downstream API. That principle maps directly to NHI governance assumptions about scope, audience, and credential reuse, and it is the right lens for MCP and token exchange. The named concept here is delegation chain scope drift: once a token can travel farther than the task that minted it, the identity boundary has already failed.
Runtime control changes the identity security control plane: static credentials, broad roles, and delayed access review are too slow for agent behaviour that can change tool sequence, destination, and timing within one task. That is why deterministic controls and live revocation have to sit in front of any detection layer. Practitioners should assume the old review model still matters, but only after the agent has been confined to an auditable operating envelope.
Agent offboarding now behaves like workforce offboarding: the article correctly frames joiner-mover-leaver handling as mandatory for agents, not optional hygiene. Once an agent has owners, scopes, environments, and downstream integrations, forgetting to decommission it becomes an access governance problem with the same failure modes as orphaned human accounts. Teams should expect shadow-agent discovery, re-approval on scope change, and hard retirement paths to become baseline governance requirements.
From our research library:
- 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, 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: Ultimate Guide to NHIs — Key Challenges and Risks
What this signals
Delegation chain scope drift: once authority can move from a user request to an agent session to a downstream API, least privilege has to be enforced per hop rather than per deployment. That is the control boundary practitioners should design to, because broad tokens fail quietly even when every component looks authenticated.
Access review cadences do not solve a problem that is already moving at session speed. Agents that can plan, call tools, and hand off authority inside one task need issuance-time control, not just periodic recertification, and the 67% of organisations still relying heavily on static credentials despite the risks they pose to agentic AI deployments shows how far many environments remain from that model, according to the 2026 Infrastructure Identity Survey.
For practitioners
- Assign every agent a distinct identity Create one directory identity per independently permissioned deployment, with a named human owner and a narrow purpose statement recorded in the registry.
- Remove borrowed and shared accounts Stop running agents under developer or pooled service accounts so agent activity stays attributable and revocation does not affect unrelated users or workloads.
- Enforce hop-by-hop delegation limits Require strict token exchange profiles with one audience per token, no passthrough at MCP servers, and downscoping at each downstream hop.
- Separate deterministic control from detection Use allowlists, egress policy, sandboxing, and approval gates first, then layer behavioural baselining over the authorised envelope.
- Build agent offboarding into lifecycle governance Tie agent retirement, scope changes, and quarterly shadow-agent discovery to the same lifecycle process used for workforce access reviews.
Key takeaways
- AI agents become governance problems the moment they borrow human or shared service identities, because attribution and revocation both stop being clean.
- The article's core control model is narrow delegation at every hop, backed by short-lived credentials and one-audience token exchange.
- Deterministic runtime controls should constrain agents before execution, while behavioural monitoring only watches the authorised envelope.
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, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets 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 agent authority being widened through borrowed accounts and unsafe delegation. |
| Recommendation — Constrain agent privileges at deployment and session level so identity abuse cannot expand authority at runtime. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Shared and inherited access are the main risk pattern described for AI agents. |
| NHI-07 — Long-Lived Secrets | The article argues for short-lived credentials and removal of static keys from agent workflows. | |
| Recommendation — Scope each agent to the minimum viable access and eliminate inherited human or pooled service privileges. Replace static credentials with short-lived tokens and revoke any durable secrets that agents still use. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential issuance, rotation, and revocation are central to the article's control model. |
| Recommendation — Manage agent authenticators so token lifetime, revocation, and rotation match the task's risk. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The abuse path described depends on credential misuse and movement across tools and APIs. |
| Recommendation — Map agent misuse to credential access and lateral movement patterns to improve detections and triage. | ||
Key terms
- 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.
- 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.
- Runtime control: Controls that enforce policy while an AI system is operating, rather than after the fact. For healthcare chatbots, runtime control includes data masking, output filtering, access scoping, and immutable logging so the organisation can defend the interaction itself.
- Shadow Agent: An AI agent deployed without formal registration, identity governance, or security oversight, the agentic equivalent of shadow IT. Shadow agents are more dangerous than typical shadow NHIs because they actively take actions using their credentials.
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 July 14, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org