The Agentic Identity Gap
Zero Trust Got Identity Right. Agentic AI Got It Wrong.
Zero Trust architectures have placed identity at the centre of security: 'Never trust, always verify.' Every human gets a persistent, auditable identity tied to their actions. Every system logs which identity performed which action. It's working—enterprises are seeing measurable security improvements. But autonomous agents exist in an identity blind spot. When an agent makes a decision, takes an action, or triggers a workflow, the audit trail doesn't say which agent did it. It says which human is running the system. This is the agentic identity gap, and it's creating a serious compliance and security problem.
Why This Matters
Imagine a scenario where an autonomous agent processes a financial transaction, makes a policy decision, or deletes data. A compliance audit asks: 'Who approved this?' The honest answer is: 'Nobody—a machine did it, but we're not sure which one or why.' This fails basic compliance requirements in regulated industries. Financial services, healthcare, and government all require knowing exactly who or what authorised each material action. Additionally, if something goes wrong—a wrong decision, a security incident, or a data breach—organisations need to know which agent did it so they can investigate root cause and prevent it from happening again. With the agentic identity gap, that's impossible.
The Technical Gap
The technical problem is that today's agent frameworks aren't designed for multi-agent, auditable operations. When a single human user runs an application that triggers agent logic, the logs attribute everything to that user, not to the agent. This works for single-agent scenarios but falls apart as soon as you have multiple agents, scheduled agents, or agents calling other agents. Cloud identity services (Azure AD, Okta, AWS IAM) are built around human identities and service identities, but service identities don't have the granularity to represent individual agents making decisions within a larger system.
What Agentic Identity Should Look Like
An agentic identity system would provide each agent with a scoped, auditable identity that persists across actions. When Agent-A processes a document, the audit log says 'Agent-A processed it,' not 'User-Bob's service processed it.' Agentic identities should be machine-readable and tied to agent definitions (model version, prompt version, configuration) so you can correlate decisions to specific agent implementations. Access policies would be per-agent: 'Agent-Classification can read documents and write to the classification database. Agent-Approval cannot write to the classification database without Agent-Classification having already classified.' Cross-agent calls would be explicit and logged. All of this should integrate with Zero-Trust architectures so agentic identities are treated like any other identity in your environment.
The Road Forward
This is an emerging pattern, not yet standardised. Standards bodies are starting to work on it (OpenID Foundation has draft specs for service identity extensions, and NIST is publishing guidance on AI system auditability). In the near term, enterprises deploying autonomous agents should architect their own agentic identity layer: assign each agent a unique, scoped service principal. Log agent decisions separately from human actions using structured telemetry. Use agent version identifiers (or SHAs of agent definitions) so you can correlate decisions to implementations. Build compliance dashboards that show agent actions per agent, not per human. As the ecosystem matures, these patterns will get standardised and tooling will improve. But today, agentic identity is a deliberate architecture choice, not a default. Make it.
Arkaya Team
Cyber Security & Agentic AI Practices