Agent Identity vs Agent Session Identity: where to anchor accountability for each run

When an AI agent misbehaves, the first question is "which run did that?", and many deployments cannot answer it because every run of the agent authenticates as the same identity. Teams designing agent identity face a real architectural choice: give each agent definition one durable identity that all its runs share, or issue a distinct identity (or identity-bound context) to each run, session or instance. The choice decides how precisely you can attribute an action, how surgically you can revoke, how much audit data you carry and how much identity sprawl you create. This guide compares the two models by threat model, architecture, failure modes and controls, then gives decision criteria, a worked scenario and a hybrid pattern that most production estates end up with. It is for identity architects, platform engineers and security leads building or governing agent platforms. For the wider field, start with the Agent Identity and Access Guide; for why agents should not run on shared service accounts at all, see AI Agent Identity vs Service Account.

Key takeaways

• The short answer is "who" versus "which run". An agent identity names the agent definition (its code, prompt, tools and owner); a session identity names one execution of it, so logs and revocation can point at a single run.
• Durable identity is where permissions and ownership belong. Grants, owners, recertification and inventory attach cleanly to something that lives as long as the agent definition does.
• Session identity is where attribution and containment belong. A per-run identifier, credential or token lets you stop one compromised run without breaking every other run of the same agent.
• Pure per-session identity in the directory creates sprawl. Minting a full directory principal for every run multiplies objects, grants and clean-up jobs; most designs keep the principal durable and make the credential or token per run.
• The working pattern is layered. Durable agent identity for authorisation, short-lived per-run credentials or transaction context for attribution, and a run identifier that every log line and downstream token carries.

The short answer

Both models answer "who is acting?", at different granularity. In the agent identity model, one principal represents the agent as a product: "invoice-triage-agent, owned by Finance Operations, version 4". Every run, on every host, at every hour, authenticates as that principal. In the agent session identity model, each run gets something unique to it: its own principal, its own short-lived certificate or token, or at minimum a unique run identifier bound into the credentials it presents.

The standards bodies frame the same distinction in workload terms. The IETF WIMSE architecture (draft-ietf-wimse-arch-08, an Internet-Draft last updated 6 July 2026, checked November 2026) treats a workload as a logical entity and an instance as a running copy, notes that the number of instances varies with scaling and orchestration, and leaves the granularity of the identifier to the issuing trust domain's policy. SPIFFE defines a workload as software deployed for one purpose that may comprise multiple running instances, which is why one SPIFFE ID commonly covers many replicas. Agents push this question harder than ordinary services because two runs of the same agent can take very different actions on different inputs. See the WIMSE Workload Identity Architecture Guide and the SPIFFE and SPIRE Guide.

Side-by-side comparison

Agent identity per definition in depth

Threat model

The durable identity is a standing credential with standing permissions. If its secret leaks, an attacker holds everything every run could ever do, for as long as the secret is valid. If one run is steered by prompt injection or a poisoned document, its actions are indistinguishable in the identity layer from legitimate runs. The relevant ATT&CK technique is T1078.004 Cloud Accounts (valid account abuse), and where tokens are lifted from a run, T1550.001 Application Access Token.

Architecture in words

The orchestrator holds one credential (a client secret, certificate or federated workload identity) for the agent principal. Each run requests an access token as that principal and calls tools and APIs. Logs show the principal; the run is identified only by whatever correlation ID the application chooses to emit. The cloud platforms model this layer explicitly. In Microsoft Entra Agent ID, an agent identity blueprint is a template from which agent identities are created; each agent created from a blueprint has its own identity and permissions, credentials are configured on the blueprint, and disabling the blueprint stops all its agent identities authenticating. In Google Cloud Agent Identity, the principal is derived from the ID of the hosting resource, and a redeployed agent receives a new resource ID and therefore a new principal. In Amazon Bedrock AgentCore Identity, agent identities are a specialised kind of workload identity held in an agent identity directory that acts as a unit of governance. Platforms are listed alphabetically in the companion Cloud Agent Identity Services Compared (Entra, AgentCore, Google).

Failure modes

• All-or-nothing containment: stopping one bad run means disabling or rotating the agent identity, which stops every healthy run too, so teams hesitate and the bad run keeps going.
• Forensics by inference: investigators join application traces to identity logs by timestamp, which breaks under concurrency.
• Standing privilege creep: permissions accumulate to cover the union of every task any run might perform.

Controls

• Short credential lifetimes: prefer federated or certificate-based credentials over long-lived secrets. Google Cloud's agent identity certificates are valid for 24 hours and renewed automatically.
• Named owner and recertification: attach a human owner and review on change (new tool, new model, new data source). See Agent Identity Recertification.
• Mandatory run identifier in logs: even without session identity, require every tool call to log a run ID generated by the orchestrator.

Agent session identity per run in depth

Threat model

Session identity narrows the prize. A stolen per-run credential is valid only for that run's lifetime and, if scoped well, only for that run's task. A hijacked run can be cut off alone. The new risks move to the issuer: whatever mints per-run identities is now a high-value target (T1098 Account Manipulation if an attacker can create or modify identities), and an issuer that grants each run the full template permissions gains attribution without gaining least privilege.

Architecture in words

There are three common implementations, from heaviest to lightest:

1. Per-run principal: the orchestrator creates a directory identity for each run from a template and deletes it at the end. Strongest separation, highest sprawl risk.
2. Per-instance workload credential: each container or process receives its own short-lived certificate or token, with the run or instance identifier encoded in it, while the logical principal stays durable. This is the SPIFFE and WIMSE pattern applied to agents.
3. Per-transaction context token: the durable agent identity authenticates, and a short-lived signed token carries the run context through the call chain. The OAuth Transaction Tokens draft (draft-ietf-oauth-transaction-tokens-11, an Internet-Draft dated 30 July 2026, checked November 2026) describes short-lived signed JWTs, expected to live minutes or less, with a required unique txn transaction identifier that workloads can log for audit and use to detect replay. Drafts change, so avoid depending on claim details. See the OAuth Transaction Tokens (Txn-Tokens) Guide.

Delegation adds another layer. When a run acts for a user, OAuth token exchange (RFC 8693) lets the token carry both the subject and the current actor in the act claim, with nested act claims recording prior actors in a chain. Only the top-level claims and current actor are meant for access decisions; prior actors are informational. That separation is what lets a per-run actor appear in the token without becoming the subject. See the OAuth Token Exchange and Delegation Guide.

Failure modes

• Identity sprawl: thousands of per-run principals per day overwhelm inventory, access reviews and directory quotas.
• Orphaned grants: runs crash before clean-up, leaving principals or bindings behind. Google Cloud documents that deleting an agent leaves its IAM bindings as inactive grants to remove manually, the same pattern at the agent level.
• Attribution without restriction: every run inherits the full template scope, so per-run identity improves forensics but not blast radius.
• Broken correlation: the run ID exists at the identity layer but downstream tools drop it, so the chain breaks after the first hop.

Controls

• Template-bound issuance: per-run identities may only be issued from an approved agent definition, never ad hoc.
• Per-task down-scoping: request only the scopes the task needs at issuance. See Delegation Chains and Attenuated Authority for AI Agents.
• Expiry as clean-up: prefer credentials that expire on their own over principals that must be deleted.
• Re-bind at every hop: WIMSE section 3.4.11 says that in multi-hop agent chains each hop must explicitly scope and re-bind the security context.

Attribution, revocation and audit trade-offs

The audit design matters as much as the identity model. Agree a schema where every record carries agent identity, run identifier, acting-for user (if any), tool, target and outcome. The AI Agent Audit Log Schema Template gives a starting point, and Agent Observability vs Audit Logging covers why traces alone are not evidence.

Decision criteria

• Choose agent identity alone when: the agent is low-risk (read-only, internal data), runs are few and sequential, and the orchestrator reliably emits a run ID. Small organisations with one or two agents often stop here, with short-lived credentials.
• Add per-run credentials or transaction context when: runs are concurrent, the agent can write, delete or spend, it processes untrusted input (email, tickets, web pages), or you need to contain one run without an outage.
• Use per-run directory principals only when: regulation or contract requires distinct accountable identities per execution, or target systems can only attribute by principal and cannot read token claims. Budget for automated deletion and review tooling first.
• Acting for users changes the picture: where a run acts on a user's behalf, the delegation token already differs per user; add the run as actor rather than inventing a separate scheme. See AI Agent Service Accounts vs On-Behalf-Of Access.
• Large estates: standardise one pattern platform-wide (durable principal plus per-run credential is the common choice) so that detection rules and audit queries work across agents.

Worked scenario: an accounts payable agent

A finance team runs an accounts payable agent that reads supplier emails, matches invoices and schedules payments. At peak it runs 40 concurrent sessions. It started with one agent identity holding read access to the mailbox and write access to the payments API.

A supplier email carries injected instructions, and one session schedules a payment to a new account. The investigation finds the payments API log shows only the agent identity. Disabling it would halt month-end processing, so the team kills the orchestrator process and waits for the credential to rotate. Linking the payment to the email takes two days of trace correlation.

The redesign keeps the durable agent identity, owned by the finance systems lead, as the only grant holder. Each session now receives a credential valid for 15 minutes, carrying the session ID, issued only by the orchestrator, and down-scoped: sessions that have not completed invoice matching cannot obtain the payment-scheduling scope. Payment creation above a threshold requires a human approval step outside the agent. Every tool call logs the session ID, and the payments API records it from the token. A repeat incident would now show the exact session in the payments log, the session credential can be cut off alone, and the other 39 sessions keep running. The pattern mirrors the lesson of the PocketOS Database Deletion 2026, where an agent used an account-scoped token found in an unrelated file: scope per purpose, and keep destructive actions behind a check outside the agent.

Implementing the layered pattern

1. Inventory agents and runs: list each agent definition, its owner, its current credential type and whether runs are concurrent. Mark agents that act for users.
2. Fix the durable layer first: one principal per agent definition (never shared between agents), short-lived or federated credentials, named owner. See Shared credentials between AI agents.
3. Introduce a run identifier: the orchestrator generates it, injects it into every tool call and log record, and you verify downstream systems record it.
4. Bind run context into credentials: issue per-run tokens or certificates carrying the run ID, starting with the highest-risk agent. Test in a pilot with logging only, then enforce that tools reject calls without run context.
5. Down-scope per task: map tasks to scopes and issue the minimum per run.
6. Wire containment: give the SOC two switches, revoke one run and disable the template. Rehearse both. See the AI Agent Kill Switch and Containment Guide.
7. Rollback: keep the durable credential path available behind a feature flag during rollout, so a broken issuer does not stop the business; remove it once the issuer has met its availability target.

Detection and measurement

• Monitor: agent principal use outside the orchestrator's network or workload identity; per-run credentials used after their run ended; the same run ID appearing from two sources; issuance of run credentials from unapproved templates; directory object counts for agent principals.
• Run attribution rate: percentage of privileged agent actions in target-system logs that carry a run identifier. Aim for 100% on write and delete actions.
• Median credential lifetime: for agent runs, tracked per agent; it should fall as session credentials replace standing secrets.
• Single-run containment time: from detection to the run being unable to call tools, measured in exercises.
• Orphaned identity count: per-run principals or bindings older than the maximum run length. Target zero.
• Scope reduction ratio: average scopes per run credential divided by scopes on the agent template.

Common failure patterns

• Sharing one identity across agents: the worst of both worlds; neither the agent nor the run can be told apart.
• Run ID only in the application log: it never reaches the systems the agent changed, so it cannot be used as evidence.
• Per-run principals without clean-up: the directory fills with stale agent objects that still hold grants.
• Per-run tokens with template-wide scope: attribution improves, blast radius does not.
• No template-level switch: when the agent definition itself is compromised, operators chase runs one by one.

Framework mapping

Practitioner checklist

• Every agent definition has its own principal and a named human owner.
• No two agents share credentials, and no agent uses a human account.
• Agent credentials are federated, certificate-based or otherwise short-lived.
• The orchestrator generates a run ID and every tool call carries it.
• Target systems record the run ID or run-bound token claims, verified by test.
• High-risk agents receive per-run credentials down-scoped to the task.
• Per-run identities can only be issued from approved templates.
• The SOC can revoke one run and disable a whole template, and has rehearsed both.
• Orphaned per-run principals and bindings are swept automatically.

Standards and references

• IETF: Workload Identity in a Multi System Environment (WIMSE) Architecture, draft-ietf-wimse-arch
• IETF: Transaction Tokens, draft-ietf-oauth-transaction-tokens
• IETF: RFC 8693 OAuth 2.0 Token Exchange
• SPIFFE: SPIFFE Concepts
• NIST NCCoE: Software and AI Agent Identity and Authorization project
• Amazon Web Services: AgentCore Identity terminology
• Google Cloud: Agent Identity overview
• Microsoft Learn: Agent identity blueprints

Related NHI Mgmt Group resources: Agent Identity and Access Guide · AI Agent Identity vs Service Account · WIMSE for AI Agents Guide · AI Agent Credential Lifecycle and Rotation Guide