TL;DR: AI agents often authenticate with borrowed human credentials or shared service accounts, which makes cross-tool attribution and delegation unreliable and leaves downstream systems unable to verify which agent actually acted, according to Preamble. Cryptographic agent identity, not runtime labels, becomes the missing control when agents touch real data and production systems.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Preamble's blog post: AI agents still lack cryptographic identity across tools and trust boundaries, so borrowed credentials and shared accounts make attribution unreliable.
Why it matters: IAM and security teams need a verifiable identity model for agents before they are allowed to access databases, APIs and production workflows, or auditability and delegated authority break down.
Context
AI agent identity is the ability to prove which specific agent instance acted, not just which user or service account supplied the credentials. In most deployments, that proof is missing, so tool calls, approvals and downstream requests collapse into a single shared identity trail. Agentic AI Identity Guide
The governance gap is not authentication alone. Existing IAM patterns can authenticate a process or a user, but they do not automatically create a portable, cryptographically verifiable identity for an agent that crosses tools, runtimes and approval chains.
Key questions
Q: How do agents get cryptographic identity across tools?
A: Agents get cryptographic identity across tools by using workload credentials such as OIDC tokens, SPIFFE/SPIRE SVIDs, mTLS certificates, or signed assertions that each tool can verify. The tool then binds requests to a verifiable identity, so the agent can be authenticated, authorised, and audited without sharing human passwords or long-lived API keys.
Q: Why do shared service accounts make agent governance harder?
A: Shared service accounts make it harder to prove which employee initiated the work and which agent actually performed it. They blur identity lineage, weaken audit evidence, and can grant more access than the task requires. In agent workflows, that creates accountability debt because the organisation loses a clear chain from human intent to machine action.
Q: How does delegated access work in multi-agent systems?
A: Delegated access in multi-agent systems should use scoped, short-lived credentials that carry the originating principal, the delegated scope, and the target resource. Each agent must call tools only within that delegated context, with policy checks that prevent privilege confusion, stop one agent from acting as another, and block the confused deputy problem.
Q: What should teams do first when agent approvals can be spoofed?
A: Teams should first require cryptographic approval verification, such as signed approval tokens, mutual TLS, or challenge-response confirmation tied to a specific agent and request. That removes spoofable prompts or messages from the trust path, so approvals cannot be forged by a fake agent, replayed, or detached from the authorised action.
Technical breakdown
Why runtime labels are not agent identity
A runtime label such as a name, role or sender field helps route work inside one application, but it does not prove who originated an action after the message leaves that boundary. Cryptographic identity requires a stable binding between the agent instance, the message and the receiving system's verification logic. Without that binding, logs record a claim rather than evidence, and a compromised or impersonating agent can blend into ordinary workflow traffic.
Practical implication: Treat runtime identifiers as trace metadata only unless the receiving system can verify cryptographic proof for each action.
Borrowed credentials turn agents into indistinguishable users
When an agent runs on a human's OAuth token, API key or session cookie, every downstream system sees the human identity rather than the agent instance. That makes non-repudiation impossible and creates a broad trust collapse: the same audit trail could reflect a person, a delegated task, or a compromised process. In practice, the identity model is hidden inside the credential, so revocation, scoping and attribution all become blunt instruments. Read the Ultimate Guide to NHIs.
Practical implication: Separate the actor that holds a credential from the actor that performs the work, or you lose meaningful attribution and delegation control.
Shared service accounts erase agent-level accountability
A shared service account gives multiple agents the same authentication surface, so the infrastructure can only tell that 'the account' acted, not which agent instance did it. That is workable for coarse service access, but it breaks investigation, selective revocation and per-agent policy enforcement. It also creates a confused deputy path, because one agent can persuade another to act under the same authority without any durable delegation record. See the Service Account Security Guide.
Practical implication: Use distinct identities per agent instance where accountability or scoped delegation matters.
Threat narrative
Attacker objective: The attacker aims to make malicious agent activity look like normal delegated work so the system cannot assign responsibility or block the action.
- Entry occurs when an agent is granted borrowed credentials or a shared account that downstream systems treat as legitimate access.
- Escalation follows when another agent, a prompt injection or a spoofed sender field reuses that same authority to make requests the original actor should not control.
- Impact arrives when approval, data access or deployment actions are accepted without proof of which agent instance actually initiated them.
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.
- 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
Agent identity is not a naming problem, it is a proof problem. Runtime labels, role names and declared senders are useful inside one orchestration layer, but they do not survive trust boundaries as evidence. If a receiver cannot verify the agent instance cryptographically, the identity claim is only a convenience label. Practitioners should treat that distinction as the dividing line between observability and enforceable control.
Borrowed credentials collapse the distinction between user, process and agent. When an agent authenticates with a human's token or cookie, every downstream system sees the human, not the actor that actually decided to call the tool. That breaks audit integrity and makes delegated access indistinguishable from direct access. Human vs Non-Human Identity captures the governance tension, but agentic systems intensify it because the actor can change behaviour mid-session.
Shared service accounts create identity reuse at the exact layer where attribution matters most. The same credential can be reused by multiple agent instances, so no receiving system can tell which agent approved, queried or deployed. That is a structural accountability failure, not just a logging gap. The practical conclusion is that agent identity must be unique enough to support revocation, traceability and delegation policy at the instance level.
Cryptographic agent identity is the named concept this market lacks. Preamble's analysis shows that existing frameworks mostly authenticate the client application or the user, not the specific agent instance across tools and runtimes. That is why interoperability is so weak: an identity string without verifiable binding does not solve spoofing. Practitioners should read this as a specification gap, not a tooling gap.
Delegation without an explicit identity chain becomes confused deputy risk at scale. Once one agent can ask another agent with broader access to act on its behalf, permissions become transitive unless the system records and enforces that delegation. The failure is not just that broad privileges exist, but that authority can be borrowed informally. Security teams need to treat agent-to-agent delegation as a governed trust relationship, not an internal convenience.
From our research library:
- 69% of organisations still authenticate machine identities with long-lived API keys, according to the 2026 State of AI Agent Identity Security Report.
- Read next: Agentic AI Identity Guide
What this signals
Cryptographic agent identity is the new control boundary: once agents can call tools, move data and hand work to one another, the security question shifts from 'who launched it' to 'which instance can prove it acted'. Identity programmes that stop at user tokens or service account labels will not survive that shift.
Preamble's research shows 69% of organisations still authenticate machine identities with long-lived API keys, according to the 2026 State of AI Agent Identity Security Report. That pattern becomes more fragile when agents can impersonate one another, so delegation policy has to move from trust-by-label to proof-by-message.
For practitioners
- Define a per-agent identity model Assign each agent instance a unique identity that can be verified by receivers before accepting tool calls, approvals or data requests.
- Stop reusing human credentials for agent workloads Move agents off borrowed OAuth tokens, API keys and session cookies so the audit trail reflects the real actor rather than the user who launched it.
- Replace shared service accounts with instance-level credentials Give each agent its own scoped credential so you can revoke one agent without breaking the rest of the fleet.
- Record delegation chains for every agent-to-agent handoff Log which agent asked, which agent acted and which policy allowed the transfer, so approvals are not treated as implicit trust. See the OWASP Agentic Top 10 ASI03 Guide.
- Verify sender authenticity before accepting approvals Require cryptographic proof on approval messages and tool responses so a spoofed role cannot satisfy downstream automation.
Key takeaways
- Agent identity fails when systems rely on runtime labels or borrowed credentials instead of cryptographic proof tied to the specific instance.
- The core risk is not just weak audit data, but the inability to distinguish one agent's action from another's across tools and trust boundaries.
- Verifiable identity, unique credentials and explicit delegation records are the controls that make agent actions attributable and governable.
Related NHI Mgmt Group resources: Agentic AI Identity Guide · Ultimate Guide to NHIs · Service Account Security Guide · Human vs Non-Human Identity
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 post centres on agents reusing borrowed credentials and spoofing one another across trust boundaries. |
| Recommendation — Bind each agent action to a verifiable identity and privilege scope before allowing tool execution. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Agents authenticate with borrowed credentials and shared accounts rather than a durable agent identity. |
| NHI-05 — Overprivileged NHI | Agents inherit broader access than they need when credentials are shared or borrowed across workflows. | |
| Recommendation — Replace shared authentication paths with per-agent credentials and receiver-verifiable assertions. Scope each agent identity to the minimum permissions required for its task and delegation chain. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential lifecycle and reuse are central because agent authority is carried through tokens and API keys. |
| Recommendation — Manage agent authenticators as distinct assets with rotation, revocation and scoped assignment. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article describes credential reuse and agent-to-agent abuse that supports both access and movement across systems. |
| Recommendation — Map agent impersonation paths to credential access and lateral movement detections in your telemetry. | ||
Key terms
- Agent Handoff: Agent handoff is the point at which a system passes an unresolved case from structured automation to an AI agent. The handoff should occur only after the workflow has collected context, because the agent is then extending evidence rather than inventing a case from scratch.
- Shared Service Account: A shared service account is a single non-human identity used by multiple systems, applications, or teams to access resources under one credential set. In IAM and NHI governance, it weakens accountability and least privilege because activity cannot be cleanly traced to one workload, person, or automated process.
- Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
- OAuth Token: A short-lived access credential issued by an OAuth 2.0 authorisation server granting an NHI scoped access to specific resources for a defined period. Preferred over static API keys because their short lifetime limits the exploitation window if intercepted.
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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org