AI Agent Identity Architecture: From Service Accounts to Identity Propagation

Service accounts are one of those infrastructure patterns so deeply embedded in enterprise IT that nobody questions them anymore. Need a system to call an API? Service account. Need an automation to access a database? Service account. Need an AI agent to interact with your CRM, ticketing system, and knowledge base? Service account.

That last use case breaks the model. And the organizations that defined enterprise identity, Google and the Coalition for Secure AI, said so explicitly in January 2025. Google Cloud's Secure AI Framework guidance recommended that organizations stop using service accounts for AI agents entirely. CoSAI's strategic update called for organizations to "define new identity and access paradigms for AI agents," language that positioned service accounts as the old paradigm being replaced.

This was not a suggestion from mid-level researchers. This was coordinated guidance from an organization representing Google, Microsoft, Amazon, and dozens of major technology companies. The service account model for AI agents was being deprecated in real time.

The variable that determines your exposure is identity fidelity: how accurately your systems can trace an AI agent's actions back to the specific human who initiated them. With service accounts, identity fidelity is zero. Every user's actions look identical in the audit log because they all execute under the same service identity. With proper identity propagation, fidelity approaches one-to-one. That difference is not academic. It is the difference between passing a SOX audit and failing one, between detecting unauthorized access and missing it entirely, between knowing who did what and guessing.

Why Service Accounts Worked Until They Didn't

The logic behind service accounts for traditional automation is sound. A batch job that reconciles financial records nightly does not have a "user." A cron job that rotates log files does not act on anyone's behalf. These are system-level operations, and system-level identity is the correct abstraction.

Service accounts also simplified permissions management. Instead of propagating individual user credentials through automated workflows, you create one account with the necessary access. It is clean, auditable at the system level, and has been the standard pattern for two decades.

The model breaks when the automated system acts as a proxy for a human user making dynamic decisions. An AI agent that searches the company knowledge base, drafts an email, updates a customer record, and schedules a meeting is not performing a system operation. It is performing a user operation: with the user's intent, affecting the user's data, in the user's context.

When that agent operates under a service account, three things break simultaneously.

Permission checks evaluate the wrong identity. The backend systems see the service account's permissions, not the user's. If the service account has broad access (which it typically does, because the agent serves many users with different needs), every user effectively operates with the service account's elevated privileges. A junior employee asking the AI assistant for a document gets results from the full corpus the service account can access, including executive communications, legal correspondence, and HR records the employee is not authorized to see.

Audit logs record the wrong identity. When the agent modifies a customer record, the audit trail shows the service account, not the user who initiated the action. In any regulated environment (SOX, GDPR, HIPAA), this breaks compliance. A HIPAA audit requires knowing which specific user accessed a patient record. A service account entry does not satisfy that requirement.

Privilege boundaries dissolve. The service account's broad permissions become a de facto privilege escalation for every user the agent serves. And because the agent is autonomous, deciding which tools to invoke and which data to access based on natural language input, the exposure surface is dynamic and unpredictable.

OIDC Identity Propagation Reference Architecture

The replacement architecture propagates the authenticated user's identity through every hop in the agent's workflow. Three layers must work together.

Layer 1: Front-End Authentication

The user authenticates to the application that hosts the AI agent. Standard OIDC (OpenID Connect) flow: the user proves their identity, the application receives an ID token and access token scoped to the user's identity and permissions.

This layer exists in most enterprise applications already. The change is what happens next.

Layer 2: Identity Propagation

When the agent needs to call a backend service, it does not use a service account credential. Instead, it exchanges the user's token for a new token scoped to the specific backend, using the OAuth 2.0 On-Behalf-Of (OBO) flow.

The OBO flow works as follows. The agent's application holds the user's access token from the front-end authentication. When the agent needs to call Backend Service X, the application sends a token request to the authorization server that says, in effect: "I am acting on behalf of this user. Issue me a token for Backend Service X with this user's permissions." The authorization server validates the request, checks the user's permissions for Backend Service X, and issues a new access token scoped to that specific backend and that specific user.

The critical property: the downstream token carries the user's identity and authorization scope, not the application's. Backend Service X sees the user's permissions, enforces the user's access policies, and logs the user's identity.

Layer 3: Backend Authorization

Each backend system the agent touches evaluates the propagated token against its own authorization policies. The user's permissions at each backend determine what the agent can do. If the user cannot access executive documents in the knowledge base, the agent operating on their behalf cannot access them either, regardless of what the agent's application-level permissions might allow.

The Complete Flow

User authenticates → Application receives user token
                  → Agent determines it needs Backend A
                  → Application exchanges user token for Backend A token (OBO)
                  → Agent calls Backend A with user-scoped token
                  → Backend A evaluates user's permissions
                  → Backend A logs user's identity in audit trail
                  → Agent determines it needs Backend B
                  → Application exchanges user token for Backend B token (OBO)
                  → (Same pattern repeats for every backend)

At every hop, the user's identity is preserved. At every backend, the user's permissions are enforced. In every audit log, the user's actions are traceable.

OAuth 2.0 On-Behalf-Of Flow Implementation

Prerequisites

Your identity provider must support the OBO flow. Microsoft Entra ID (formerly Azure AD) supports it natively. Google Cloud IAM supports it through domain-wide delegation and token exchange. Okta and Auth0 support it through token exchange extensions.

If your identity provider does not support OBO, that is a gap that needs immediate attention. Without OBO or an equivalent token exchange mechanism, identity propagation is architecturally impossible.

Implementation Steps

Step 1: Register the agent application. In your identity provider, register the AI agent's application as a confidential client. Configure it with the permissions it needs to request OBO tokens for each backend service.

Step 2: Configure downstream APIs. Each backend service must be registered as a resource server in your identity provider. Define the scopes that the service supports. Configure the service to accept and validate tokens issued through the OBO flow.

Step 3: Implement token exchange in the agent middleware. When the agent determines it needs to call a backend service, the middleware layer intercepts the call. It takes the user's access token, sends a token exchange request to the authorization server specifying the target backend, and receives a new token scoped to that backend with the user's permissions. The middleware then attaches this token to the backend API call.

Step 4: Handle token lifecycle. OBO tokens have their own expiration. The middleware must handle token refresh, caching (to avoid redundant token exchanges for repeated calls to the same backend within a session), and revocation propagation (if the user's permissions change during the session, cached tokens must be invalidated).

Step 5: Implement fallback behavior. If the OBO token exchange fails (the user lacks permissions for the target backend, the authorization server is unavailable, the token is expired and cannot be refreshed), the agent must fail gracefully. It must not fall back to a service account credential. The failure should be surfaced to the user with a clear explanation: "You do not have permission to access this resource."

Active Directory Audit Checklist for Non-Human Accounts

Before implementing identity propagation, you need to understand your current state. This checklist identifies the service accounts that AI agents are currently using and assesses the risk of each.

1. Inventory all service accounts used by AI systems.

Query Active Directory (or your identity provider) for accounts with names that suggest AI or automation usage. Check application configurations for hardcoded service account credentials. Review API gateway logs for service accounts that authenticate to backend systems on behalf of AI applications.

2. For each service account, document:

Which AI agent or application uses this account. What backend systems the account can access. What permission level the account holds at each backend (read-only, read-write, admin). How many distinct users the agent serves under this single identity. When the account's credentials were last rotated. Whether the account has MFA enabled (most service accounts do not).

3. Risk-score each account.

Accounts scoring 8 or above require immediate migration to identity propagation. Accounts scoring 5 to 7 should be migrated within 90 days. Accounts scoring below 5 can follow a standard migration timeline.

4. Check for orphaned accounts.

Service accounts created for AI projects that were discontinued, moved, or handed off to other teams often persist with active credentials and active permissions. They are invisible to governance because no one owns them. Query for service accounts with no recent authentication activity. Query for service accounts whose associated application no longer exists.

SIEM Configuration for Agent Identity Monitoring

Detection Rule 1: Agent Action Without Linked Human Identity

Configure your SIEM to flag any action initiated by an AI agent system that does not carry a linked human identity in the audit trail. This rule detects cases where an agent is still operating under a service account rather than propagated identity. It also serves as a migration progress metric: the alert volume should decrease as you migrate agents to identity propagation.

Detection Rule 2: Permission Scope Expansion

Monitor for cases where an agent's effective permissions expand during a session. If an agent starts a session with read access to customer preferences and ends the session having accessed financial records, that scope expansion should trigger an alert. This pattern can indicate identity propagation misconfiguration (the OBO flow is granting broader permissions than intended) or session manipulation.

Detection Rule 3: Service Account Activity Anomalies

For service accounts still in use during the migration period, monitor for anomalous patterns. A service account that typically makes 50 API calls per hour suddenly making 5,000 calls. A service account accessing systems it has never accessed before. Activity outside of the expected user population's working hours.

Detection Rule 4: Token Exchange Failures

Monitor for OBO token exchange failures. A spike in failures could indicate permission misconfigurations, identity provider issues, or attempts to access resources that the user is not authorized to reach. Investigate whether the failures represent legitimate access attempts by users who lack the necessary permissions, or whether they indicate an agent attempting to access resources outside its intended scope.

Decision Matrix: When Service Accounts Are Still Acceptable

Not every AI agent interaction requires identity propagation. The decision depends on what the agent does and what data it touches.

The default should be identity propagation. Service accounts should be the exception, justified by specific constraints (the backend system does not support token-based access, the data is genuinely non-sensitive and non-regulated, the agent performs a fixed system-level function with no user context).

Migration Path: Service Accounts to Identity Propagation

Phase 1: Inventory and Risk Assessment (Weeks 1-2)

Complete the Active Directory audit checklist above. Prioritize migration based on risk scores. Document the current authentication architecture for each agent, including which backends it accesses and what credentials it uses.

Phase 2: Identity Provider Preparation (Weeks 3-4)

Verify that your identity provider supports OBO flows. Register agent applications as confidential clients. Configure downstream APIs as resource servers with appropriate scopes. Test the OBO flow in a development environment to validate that tokens are correctly scoped and that user permissions are properly enforced.

Phase 3: High-Priority Migration (Months 2-3)

Migrate agents with risk scores of 8 or above. For each agent, implement the OBO token exchange in the agent's middleware layer. Update backend API calls to use user-scoped tokens instead of service account credentials. Validate that audit logs now contain user identities for all agent-initiated actions. Run permission validation tests to confirm that the agent respects user-level access controls.

Phase 4: Remaining Migration (Months 4-6)

Migrate agents with risk scores of 5 to 7. For agents with acceptable service account usage (per the decision matrix), document the justification and implement compensating controls: enhanced monitoring, regular permission reviews, credential rotation automation.

Phase 5: Governance (Ongoing)

Ban new service accounts for AI agent use cases. Establish a review process where any new AI agent deployment must specify its identity model and justify the choice. Configure SIEM rules to detect new service account usage by AI systems.

The Identity Transition Is Not Optional

The service account model served enterprise automation for two decades. It was designed for a world where automated systems performed deterministic, predefined actions under system-level identity. AI agents operate in a fundamentally different model: dynamic, user-proxied, and autonomous.

Google and CoSAI did not deprecate service accounts for AI agents out of academic preference. They deprecated them because the alternative, anonymous overprivileged bot accounts making autonomous decisions on behalf of unidentified users, is a compliance violation, a security exposure, and an audit failure wrapped in a single architectural choice.

The identity framework has to match the agent's operating model. If the agent acts on behalf of a user, its identity must trace to that user. The tools to implement this (OBO flows, OIDC, token exchange) are mature and available. The missing piece for most organizations is not technology. It is the decision to prioritize the migration.

Start with the audit. The numbers will make the priority clear.

Nik Kale is a Principal Engineer and Product Architect with 17+ years of experience building AI-powered enterprise systems. He is a member of the Coalition for Secure AI (CoSAI), contributes to IETF AGNTCY working groups, and serves on the ACM AISec and CCS Program Committee. The views expressed here are his own.