Topic starter
11/11/2026 6:02 pm
TL;DR: Borrowed credentials and shared service accounts leave agent actions hard to attribute across tools, runtimes and frameworks, according to Preamble. Agent governance has to move from labels and roles to verifiable identity signals tied to each action.
Editorial analysis by NHI Mgmt Group, based on content published by Preamble: “Who Is This Agent? The AI Identity Crisis”.
Key questions
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Agent identity fails when systems rely on runtime labels or borrowed credentials instead of cryptographic proof tied to the specific instance.
Glossary terms: Agent Handoff, Shared Service Account, Delegated Access, OAuth Token
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
11/11/2026 6:07 pm
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.
A few things that frame the scale:
- 69% of organisations still authenticate machine identities with long-lived API keys, according to the 2026 State of AI Agent Identity Security Report.
A question worth separating out:
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.
👉 Read our full editorial: Agent identity becomes brittle without cryptographic proof