Who Is Actually Logged In? Identity When the Actor Is an AI Agent
By Domenic DiNatale
The previous pieces in this series established two claims worth holding onto. First, that most security failures trace back to architecture — not technology choices, not user behavior, but the structural assumptions baked into how systems were designed. Second, that AI applications are reproducing those same architectural failures, at scale, because the developers building them are solving capability problems rather than trust problems.
This piece follows directly from both. When an AI agent takes action in a system — reads an email, creates a calendar event, commits code, sends a message — the question of who is responsible for that action is not as simple as "the user who authorized the agent." The identity model underlying that action is more complicated, and we have not built the infrastructure to resolve it.
That ambiguity has real consequences.
The Shape of the Problem
In traditional systems, identity resolution is a point-in-time event. A user authenticates — proves who they are through credentials, a second factor, a session token — and the system records that event. Subsequent actions are attributed to that authenticated session. The audit trail reads: this user, at this time, performed this action.
That model has known weaknesses that this series has already covered. Session tokens are stolen. Credentials are replayed. The authentication event becomes a gate rather than a signal. But within its limitations, the model is at least coherent: there is a human being whose identity is being asserted, and the audit trail reflects that assertion.
AI agents break this coherence in several distinct ways.
The agent acts under delegated authority. When a user connects an AI agent to their email account, their calendar, their GitHub, their Slack, they are granting a set of permissions to something that will exercise those permissions on their behalf, without their involvement in each specific action. The authentication event ("the user authorized this agent") is temporally separated from the action event ("the agent sent this email"). The audit trail says the user authorized it. It does not say whether the user intended this specific action, reviewed it, or even knew it was happening.
The agent's behavior is indeterminate. A human user taking action in a system does so with intent that, in principle, could be reconstructed from context and testimony. An AI agent taking action in a system does so based on instructions, context, inferences, and the outputs of a model that is not fully transparent even to its developers. The specific action may have been within the scope of the agent's authorized capabilities without being within the scope of what the user intended to authorize. The distinction is meaningful but invisible to the access control system.
The agent cannot be held accountable. This is the most underappreciated dimension. Identity infrastructure serves two functions: authentication (establishing who is acting now) and accountability (establishing who is responsible when something goes wrong). Human identity satisfies both. AI agent identity, in current implementations, satisfies only the first — and even that incompletely. When an AI agent takes a harmful action under a user's delegated credentials, the accountability assignment is genuinely ambiguous in ways that don't resolve cleanly under existing frameworks.
What We're Missing
The infrastructure gap here is not primarily technical. The technical mechanisms for issuing scoped tokens, revoking access, logging actions, and requiring approval for sensitive operations all exist. The gap is in how those mechanisms are being deployed — and, more fundamentally, in whether the builders deploying them are thinking about the identity layer at all.
Most AI agent implementations today inherit their access through one of two patterns.
The first is OAuth delegation: the user connects the agent to a service using a standard OAuth flow, which issues a token with some scope of permissions. The token represents the user. When the agent exercises that token, the action is logged as the user's action. Nothing in the standard implementation distinguishes between actions taken directly by the user and actions taken by the agent operating autonomously.
The second is credential injection: the agent is provided with a credential (API key, session cookie, password) and uses it directly. This pattern is worse from a security standpoint but common in practice because it's simpler to implement. The resulting audit trail is indistinguishable from direct user access.
In neither case does the system receiving the action know it's dealing with an agent. In neither case is there a mechanism for the receiving system to apply agent-specific constraints. In neither case is the action distinguishable in audit logs from direct human action.
This is a problem for the same reason that treating authentication as a one-time gate is a problem: it conflates the initial authorization with ongoing legitimacy, and it eliminates the information that would allow you to detect when the initial authorization is being exercised in ways it wasn't intended to cover.
The Practices That Actually Help
The answer is not to stop building AI agents. It's to build them with the identity discipline that the architecture requires. A few practices follow from this.
Agent identities should be distinct from user identities. When an AI agent takes action in a system, that action should be attributable to the agent, not to the human who authorized it. This serves both audit and accountability functions. In the GitHub context I described in the previous piece — where PR reviews post under intellitech-archie[bot] rather than under my account — the distinction isn't cosmetic. It allows anyone reading the audit trail to distinguish automated analysis from human judgment, and it prevents the agent's actions from being misread as mine.
Delegated scope should be minimal and explicit. The permissions granted to an AI agent should be the minimum required for its defined function, and they should be enumerated rather than inherited. An agent that manages calendar events doesn't need access to email. An agent that reviews code doesn't need merge permissions. This is just least-privilege applied consistently — the principle has not changed, but the consistent failure to apply it to agents is producing the same blast-radius problems it produces everywhere else.
High-consequence actions should require human approval. Not because the agent will necessarily make the wrong decision, but because the accountability structure requires a human decision point in the loop. When my system generates outreach drafts, I approve each one before it sends. This is slower. It is also the only pattern that places responsibility for that outbound communication clearly with a human being who reviewed it. For low-stakes, reversible actions, autonomous execution may be appropriate. For actions that are external, irreversible, or high-stakes, human approval is not an efficiency problem — it's an accountability requirement.
Audit logs should capture agent context. An action log that says "user X sent email Y" is not an accurate record when an AI agent sent that email under user X's delegation. The record should reflect the agent's involvement — not to assign blame, but to preserve the information needed to understand what happened and why. Systems that don't maintain this distinction are building audit infrastructure that will fail them when they most need it.
The Harder Question
There is a question behind all of this that the technical practices above don't fully answer: when an AI agent takes a harmful action under delegated authority, who is responsible?
The user who granted access? Yes, in some sense — they authorized the delegation. But if the agent exercised capabilities that were technically within scope and behaviorally beyond what the user intended, the "you authorized it" framing feels inadequate.
The developer who built the agent? Possibly — if the agent behaved in ways that a reasonably designed system shouldn't have behaved. But the line between "the agent did something unexpected" and "the agent did something negligently designed" is not yet defined by law, by regulation, or by industry consensus.
The platform that provided the underlying model? Rarely — and the terms of service are structured to make this clear.
This ambiguity is not an accident. It is the natural consequence of deploying systems whose internal processes are not fully transparent, whose authorization models are not identity-complete, and whose accountability chains have not been thought through before deployment.
The security architecture problem and the accountability architecture problem are the same problem.
The Pattern Continues
This series has been tracking a single pattern through a series of contexts: the consistent displacement of architectural problems into surface-level interventions that feel like solutions but leave root causes intact. We treated phishing as a user behavior problem. We treated credential theft as a password problem. We treated MFA bypass as an MFA problem. We treated prompt injection as a prompt problem.
AI agent identity is following the same path. The current response to agent security is mostly filters, guardrails, and content policies — interventions at the surface of the problem. The structural issue — that we are deploying systems that exercise real authority under identity models that don't accurately represent what is happening — is not being addressed at the level it requires.
The infrastructure for AI agent identity exists in embryonic form. Specifications for agent attestation, standards for delegated authority chains, frameworks for agent-specific audit logging — all of these are in early development. They are not yet in wide deployment, and they will not be for some time.
In the interim, the practices above are not a complete answer. They are the closest thing available to a principled approach, applied within the constraints of what current systems support.
The gap between those practices and a fully resolved identity model is the space where the next category of incident is being built right now.
This post is part of a series on security as an architectural problem. Read the full series on the Intellitech blog.