Borrowed identities let AI agents act with hidden permissions

At a glance

What this is: NHI Mgmt Group's analysis, drawing on IndyKite's blog post: Borrowed user identity lets AI agents act with inherited permissions while obscuring attribution and governance.

Why it matters: Identity teams need a distinct governance model for AI agents that use delegated access, because human-centric audit and approval flows cannot reliably explain agent actions.

Context

When an AI agent uses a human user's existing login and permissions, the security model assumes the person and the system behind the action can be treated as the same actor. That assumption fails once the agent can make requests, touch corporate data and leave a trail that looks indistinguishable from the user's own activity.

The governance gap is not only about approval at connection time. It is about whether enterprise controls can still establish who acted, under what delegated authority, and against which data when agent identity is borrowed rather than separately governed.

That makes this a lifecycle and oversight problem for both human identity and non-human identity programmes. The article's starting point is typical of how personal agents enter enterprises: through user consent and delegated access rather than a formal security onboarding path.

Key questions

Q: What should teams do first when an AI agent borrows user access?

A: Assign the agent its own identity, then bind it to a named human owner, a limited role, and explicit per-tool permissions before it can act. If it must borrow a user session, record the delegation, time-box it, and keep a revocation path so access can be cut immediately.

Q: Why do shared user accounts make AI agent activity hard to govern?

A: Shared user accounts hide which AI agent acted, so approvals, logging and revocation cannot be tied to a specific autonomous system or accountable human. They also make least privilege and segregation of duties impossible to enforce cleanly, because one set of credentials can be reused by multiple agents, scripts or operators.

Q: How does delegated authority for AI agents work in practice?

A: Delegated authority works by letting an AI agent act under a human-granted scope that is limited to specific tools, data, actions, and time windows. Each request should be checked against policy, approved or denied, and logged with the human owner, so the agent never gains standing access beyond that request.

Q: What evidence should security teams capture for AI agent actions?

A: Capture the policy decision, the identity used, the human owner, the tool or data touched, the request parameters, the outcome, and the timestamp. Those records let teams reconstruct what the agent was allowed to do, what it actually did, and whether a control denied or approved the action.

Technical breakdown

How borrowed identity hides the real actor

Borrowed identity means the agent authenticates through the user's account or delegated token instead of a separate machine principal. The result is not just shared login, but shared authority, shared log entries and shared blame. That collapses the separation between subject, requester and executor that enterprise controls normally rely on. If the agent's actions are recorded under the employee's name, policy engines, audit pipelines and incident responders lose the signal needed to distinguish human activity from delegated automation.

Practical implication: Issue agents their own principals so logs, policy decisions and incident evidence remain attributable to the actual executor.

Why login-time approval does not govern agent behaviour

A connection approval only answers whether the agent may enter the environment. It does not answer what the agent may do after entry, how far it may reach, or whether each request still fits the original purpose. Dynamic policy has to evaluate the task context, delegated authority, data sensitivity and requester relationship on every action. Without that shift, the enterprise treats a one-time consent event as if it were a full governance decision. Read Zero Trust for AI Agents.

Practical implication: Move authorization from connection events to per-request policy evaluation that reflects task scope and data context.

Why audit needs an enterprise view of agent decisions

Agent activity trails that stay trapped inside the vendor experience are not enough for enterprise governance. Security teams need centralized evidence of who tasked the agent, what authority it used, what policy applied, what data it reached and what outcome it produced. That evidence is the difference between useful oversight and opaque automation. Without it, an organisation may know an agent was present but still be unable to reconstruct why a particular access path was allowed. See the AI Agent Observability, Audit and Incident Response Guide.

Practical implication: Route agent actions into enterprise monitoring so review, investigation and retention controls can inspect delegated decisions.

Breaches seen in the wild

• Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
• Spain's first AI agent data breach 2026: Spain's AEPD logged its first breach notification attributed to an attacker's AI agent, which altered personal data and accessed invoices.

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

Borrowed identity is an accountability failure, not just a visibility gap. When an AI agent acts under a human account, the enterprise no longer has a clean boundary between human intent and machine execution. That creates an attribution problem in audit, incident response and access governance. The practitioner conclusion is simple: treat the agent as a separate actor or lose the ability to govern its behaviour.

Connection approval is a weak control when the real risk is post-authentication behaviour. Allowing an agent to connect says nothing about whether each later action still fits the task, the data sensitivity or the delegated authority. This is where static consent breaks down and policy has to become request-specific. Enterprises should stop treating onboarding as the main control point for agent risk.

Enterprise-owned control planes matter because vendor-side trails are not sufficient for governance. If the only evidence lives in the agent provider's interface, security teams cannot consistently apply retention, investigation and monitoring standards across the environment. Centralized oversight is what makes delegated access governable at scale. The practitioner conclusion is that accountability must live in the enterprise, not only with the agent service.

Distinct agent identities are the named governance concept this model needs. AI agents should not inherit a human user's identity by default, because that destroys the separation needed for monitoring, policy enforcement and revocation. The better model is delegated authority tied to a distinct principal with traceable scope. The practitioner conclusion is to redesign governance around actor separation rather than shared identity.

Agentic AI identity becomes a cross-domain control problem when personal agents enter business systems. This is not only an access issue, and not only a monitoring issue. It sits at the intersection of delegated authority, identity lifecycle and auditability. The practitioner conclusion is to align human IAM and NHI governance so agent actions can be bounded, explained and withdrawn cleanly.

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: Agentic AI Identity Guide

What this signals

Governance programmes built for human identity assume that a user account is a stable proxy for the actor behind each request. Personal agents break that assumption when they act through borrowed identity, because the same account can now represent both human intent and machine execution in the same workflow.

Delegated identity debt: the longer organisations let agents inherit human access, the harder it becomes to prove which actions were authorised, which were agentic, and which should have been denied. That pushes identity governance away from login-centric checks and toward per-action authorization and evidence capture.

Security teams should expect more cases where the control failure is not compromise, but indistinguishable authority. Audit and incident response becomes the practical control plane for proving what happened after an agent acted inside business systems.

For practitioners

• Issue agents separate principals Create distinct identities for approved agents instead of letting them operate under a human user's account or token.
• Enforce per-request authorization Evaluate each agent action against delegated purpose, requester relationship and data sensitivity rather than relying on a one-time consent event.
• Centralize audit evidence for agent actions Record who tasked the agent, what authority it used, what policy applied and what it changed in enterprise monitoring systems.
• Limit delegated access to task scope Scope each agent to the smallest viable data and system access needed for the approved purpose, and revoke it when the task ends.

Key takeaways

• AI agents that reuse a human account create an attribution problem that standard access reviews are not designed to solve.
• The central control shift is from connection approval to per-action authorization with separate agent identity.
• Enterprise monitoring has to capture delegated authority, policy decisions and outcomes if agent governance is going to be auditable.

Related NHI Mgmt Group resources: Agentic AI Identity Guide · Zero Trust for AI Agents · AI Agent Observability, Audit and Incident Response Guide · AI Agents vs Agentic AI

Key terms

• Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions, including calling APIs, writing code, and orchestrating other agents, with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
• Delegated authority: Delegated authority is permission given to one identity to act on behalf of another within defined limits. In identity systems, it enables an agent, user, or service account to perform approved actions without owning the underlying rights, using scoped tokens, roles, or approvals to constrain access and accountability.
• Per-Request Authorization: Per-request authorization means every action is checked individually instead of trusting a session once and assuming all later activity is safe. This matters for agents because the request that causes damage may be generated after the initial interaction has already been approved. It is a stronger fit for dynamic, tool-using identities.
• Distinct Agent Identity: Distinct Agent Identity is a separate runtime identity assigned to one AI agent or autonomous process. It lets systems track the agent’s permissions, actions, and owner separately from a human account, shared service account, or other agent, which supports scoped access and revocation.

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.