AI Agent Identity vs Service Account: the four attributes a shared credential cannot carry

A service account can authenticate an AI agent, but it cannot say who is accountable for the agent, what the agent was asked to do, whose authority it is using, or which running instance made a call. Those gaps leave audit trails that stop at "the integration did it" and kill switches that stop every agent at once. This guide compares the two as identity models, not products, and concentrates on the attributes an agent identity adds: an accountable owner, a recorded intent, a delegation chain and a per-instance lifecycle. It is written for IAM architects, platform engineers and auditors deciding whether an agent can stay on a service account or needs its own identity. Delegation mechanics are covered in depth in the AI Agent Service Accounts vs On-Behalf-Of Access, and the wider NHI picture in NHI vs AI Agent Identity; this page does not repeat them.

Key takeaways

• The short answer: a service account is a credential holder, an agent identity is an accountable actor. Both authenticate a workload. Only the second records who sponsors it, why it acted, for whom, and which instance did it.
• Owner is the first missing attribute. Service accounts often have an owner field that nobody maintains. Agent identity platforms make a business sponsor mandatory and give that person defined powers to disable or retire the agent.
• Intent and delegation cannot be bolted on later. If the token does not carry the acting agent and the user it serves, no amount of log enrichment will reconstruct it reliably during an incident.
• Lifecycle must follow the instance, not the application. Agents can be created and destroyed many times a day. A service account shared across instances means one compromised instance forces you to revoke them all.
• Migration is incremental. Inventory which agents share accounts, split them one identity per agent, add sponsors, then move user-facing agents to delegated tokens. A service account can remain a valid choice for narrow, deterministic automations.

The short answer

Use a service account when the workload is deterministic, acts only on its own authority, runs as one long-lived application and has a stable owner. Use a dedicated agent identity when any of these is true: the workload chooses its own tool calls from model output, it acts for different users, it spawns short-lived instances or sub-agents, or an auditor will ask "who asked the agent to do this?".

Microsoft states that application identities, typically service principals, are built for organisation-maintained services that are expected to be long-lived with known owners, while agent identities are built for dynamic, short-lived agents that might be created and deleted thousands of times a day. Google Cloud's agent identity documentation lists the practical differences from service accounts: agent identities are not shared by multiple workloads by default, cannot be impersonated, and cannot have long-lived keys generated for them.

Side-by-side comparison

Attribute 1: an accountable owner

OWASP lists ownership failure as NHI1:2025 Improper Offboarding. With agents it is worse, because agents are often built by business users in low-code tools rather than the platform team that owns service accounts.

Threat model

An agent built by a departed employee keeps running on a service account with mailbox or CRM access. Nobody receives its alerts or can say whether its behaviour is expected, so an attacker only needs to find an agent nobody watches.

What an agent identity adds

Microsoft Entra Agent ID separates three relationships. Owners handle technical administration and can modify authentication properties, disable, delete and restore identities. Sponsors carry business accountability: they decide on renewal, extension or removal, can disable or soft-delete an agent identity, and help decide during an incident whether behaviour is expected. Sponsors are required for agent identities and blueprints. Managers place the agent in the organisational hierarchy for access requests but cannot modify or delete it. Microsoft allows up to 100 sponsors per agent identity, including dynamic membership groups, which helps survive staff turnover. See the Microsoft Entra Agent ID Guide.

Controls whichever model you use

• Make sponsorship a creation gate: no agent is registered without a named business sponsor and a technical owner, and the registry rejects personal accounts of leavers.
• Use groups for continuity: assign a team group as sponsor alongside an individual, so a departure does not orphan the agent.
• Tie sponsorship to the joiner, mover, leaver process: a leaver event triggers reassignment of every agent the person sponsors. See Ownership for Orphaned and Abandoned AI Agents and the NHI Ownership Guide.

Attribute 2: a recorded intent

A service account's purpose lives in the code that uses it. An agent's purpose is a natural-language instruction and a set of tools, and the action it takes is chosen by a model at run time. Two calls from the same agent can serve completely different requests.

Threat model

Indirect prompt injection steers an agent into a legitimate-looking API call. The resource server sees a valid token from an authorised principal. Without intent attached to the action, the security team cannot tell whether the call served the user's request or an instruction hidden in a document. This is the identity side of OWASP ASI01 Agent Goal Hijack and ASI03 Identity and Privilege Abuse. See the OWASP Agentic Top 10 ASI03 Guide.

What to record

• Registered purpose: a short statement in the agent registry, reviewed at recertification, that defines the business function and the systems in scope. Microsoft's blueprint model holds a description and app roles shared by every agent created from it.
• Task context per action: a task or conversation identifier and the initiating user, carried as token claims or request headers and written to the resource's audit log.
• Approval evidence: for consequential actions, the identity of the human who approved and the time, stored with the action record. See Human-in-the-Loop for AI Agents Guide.

Intent recording makes misuse detectable; prevention comes from task-scoped tokens, covered in Static Scopes vs Intent-Based Authorisation for AI Agents.

Attribute 3: a delegation chain

A service account can only act as itself. When an agent on a service account serves a user, the downstream system sees the account and grants the account's full rights, whatever the user is entitled to. This is the confused deputy pattern. The detail of service account versus on-behalf-of access is in the AI Agent Service Accounts vs On-Behalf-Of Access; here the point is narrower: delegation is an identity attribute the service account model has no place to store.

How the chain is represented

• RFC 8693 token exchange: section 1.1 distinguishes impersonation, where A is given all the rights B has and is indistinguishable from B, from delegation, where A remains itself and acts as an agent for B. Section 4.1 defines the act claim; nested act claims record prior actors, with the outermost being the current actor. The RFC states that prior actors are informational only for access control. Section 4.4 defines may_act, which states which party is authorised to become the actor.
• Cloud agent tokens: Amazon Bedrock AgentCore Identity describes an agent access token that contains both workload identity and user identity information, so downstream services can decide on both. Microsoft Entra agent identities can act autonomously with rights granted to them or on behalf of a user with delegated rights.
• Per-hop audience: the MCP authorization specification (2025-11-25) requires MCP servers to accept only tokens issued for them and forbids passing a received token through to upstream APIs. Each hop gets its own token, which is what keeps the chain intact.

Because nested actors are informational, policy at the resource should check the current actor and the subject, and limit chain depth at the token service. See Delegation Chains and Attenuated Authority for AI Agents and the OAuth Token Exchange and Delegation Guide.

Attribute 4: a lifecycle per agent instance

Service account lifecycle follows the application: created when the integration is built, reviewed annually, retired when the system is decommissioned. Agents do not fit that rhythm. Orchestrators spawn sub-agents per task, and hosted agents are redeployed whenever their prompt or tools change.

Threat model

Ten instances share one service account. One instance processes a poisoned document and starts exfiltrating data. To stop it you must rotate the shared credential, which breaks all ten, and you cannot tell from the logs which instance acted. The PocketOS incident shows the related failure: a coding agent found an account-scoped platform token in an unrelated file and used it for a destructive call. The agent did nothing the token did not allow. See PocketOS Database Deletion 2026: How an AI Coding Agent Used an Over-Privileged Railway Token to Wipe Production.

How the platforms handle instances

Platforms are listed alphabetically.

The template layer (blueprint, directory, hosting resource) gives you a choice of blast radius that a shared service account cannot: revoke one instance, one agent, or every agent built from one template. Platform detail is in Cloud Agent Identity Services Compared (Entra, AgentCore, Google), the AWS Bedrock AgentCore Security Guide, Google Cloud Agent Identity and the Microsoft Entra Agent ID Guide.

Lifecycle controls

• Clean up on delete: include binding and grant removal in the decommission runbook, since some platforms leave grants in place after the agent goes.
• Re-grant on redeploy deliberately: where a redeploy creates a new principal, grant through infrastructure as code so old principals are not left holding roles.
• Recertify on change, not only on calendar: a new tool, model or memory store changes what the agent can do. See Agent Identity Recertification.

Non-determinism: why the four attributes matter more for agents

A service account's permissions describe what its code will do. An agent's permissions describe the outer limit of what a model might decide to do, including under adversarial input. Three consequences follow.

• Permissions must be sized for the worst plausible decision, not the expected one. OWASP LLM06:2025 Excessive Agency names excessive functionality, excessive permissions and excessive autonomy as the root causes.
• Behavioural baselines need the task context from attribute 2, because new tool sequences are normal for an agent. See AI Agent Behaviour Baselining and Anomaly Detection Guide.
• Containment must be precise, which needs attribute 4. A kill switch that only works by rotating a shared secret is too slow and too broad. See the AI Agent Kill Switch and Containment Guide.

When a service account is still the right choice

Small organisations: start with one identity per agent and a sponsor in a simple registry; that alone fixes most attribution and revocation problems. Large organisations: use the platform template layer, enforce sponsorship in provisioning, and route delegated access through a central token service so chain depth and audience rules are applied in one place.

Worked scenario: splitting a shared support account

A support team runs three agents (triage, refund and knowledge) on one service account, svc-support-ai, holding CRM read and write, payments refund and knowledge base access. A customer email with hidden instructions makes the triage agent summarise other customers' records. The logs show only svc-support-ai reading 400 records.

1. Contain: the only lever is the shared credential, so rotating it stops refunds as well. With per-agent identities, the team would disable only the triage agent.
2. Split: create three agent identities from one support template, each with a named sponsor in the support management team and a technical owner in the platform team.
3. Scope: triage gets CRM read for the ticket's customer only; refund gets the refund API with an amount limit and approval above it; knowledge gets read on the knowledge base.
4. Delegate: the refund agent acts on behalf of the support agent handling the ticket, so the payments system records both identities.
5. Record intent: every call carries the ticket number; the SIEM rule flags CRM reads for a customer other than the ticket's customer.
6. Result: the same injection now produces a denied read and an alert naming the agent and ticket.

Migrating agents off service accounts

1. Discover: list every credential an agent runtime uses, including tokens in configuration, environment variables and MCP server settings. MITRE ATLAS AML.T0083 Credentials from AI Agent Configuration describes adversaries harvesting exactly these.
2. Classify: apply the decision table above. Mark each account as keep, split, or convert to delegated.
3. Register: put each agent in the registry with purpose, sponsor, owner and data scope before it receives a new identity. See the AI agent registry.
4. Issue in parallel: create the agent identity, grant the narrowed rights, and run the agent with both credentials available but the new one preferred, in a pilot ring of one agent per team.
5. Verify: confirm in resource logs that calls now show the agent identity, the instance and, where delegated, the user.
6. Cut over and disable: disable the service account rather than deleting it, keep it disabled for one review cycle, then delete. Rollback is re-enabling the account, which is why its rights must not be widened during the pilot.
7. Remove residue: delete stored keys, revoke OAuth consents granted to the old account and remove grants left on deleted agent principals.

Detection and measurement

• Log fields to require: agent identifier, instance identifier, acting-for subject, task or ticket identifier and approval reference on every agent-initiated call.
• Alert on: a service account previously mapped to an agent authenticating after cut-over; an agent principal used from outside its runtime; a delegated token whose subject does not match the task; IAM grants that reference deleted agent principals.

Common failure patterns

• One account per platform, not per agent: every agent in a low-code environment shares a connector identity, so attribution and revocation are impossible.
• Agent reuses a human-created token: an account-scoped key left in a repository becomes the agent's identity, as in the PocketOS case (OWASP NHI9 NHI Reuse).
• Sponsor set to the builder and never reviewed: the field exists but goes stale when the builder leaves.
• Delegation flattened at a proxy: a gateway or MCP server forwards the user's token or swaps it for its own service token, losing the chain the resource needs.
• Agent deleted, grants kept: the runtime is removed but role bindings and OAuth consents remain, ready for a redeployed principal or a name collision.
• Treating instructions as access control: "only touch staging" in the prompt is not a permission boundary.

Framework mapping

Practitioner checklist

• Every agent that takes actions has its own identity, not a shared service account.
• Each agent identity has a named business sponsor, a technical owner and a group backup.
• Registered purpose and data scope are recorded and reviewed at recertification.
• Agent calls carry agent, instance, acting-for subject and task identifiers into resource logs.
• User-facing agents use delegated tokens that name both the agent and the user.
• No proxy or MCP server passes a received token through to another service.
• No long-lived exportable keys exist for agent identities; secrets in agent configuration are removed.
• Decommissioning removes grants, consents and stored credentials, not only the runtime.
• A single agent instance can be disabled in minutes without affecting others.

Standards and references

• IETF: RFC 8693 OAuth 2.0 Token Exchange
• Model Context Protocol: Authorization specification (2025-11-25)
• NIST NCCoE: Software and AI Agent Identity and Authorization project
• OWASP: Non-Human Identities Top 10 2025
• Amazon Web Services: AgentCore Identity terminology
• Google Cloud: Agent Identity overview
• Microsoft Learn: Owners, sponsors and managers for Agent ID
• Microsoft Learn: Agent identity blueprints

Related NHI Mgmt Group resources: Agent Identity and Access Guide · API Keys vs Service Accounts · Shared credentials between AI agents · AI Agent Credential Lifecycle and Rotation Guide