Modern identity, workload security, and agent authentication

1. OAuth 2.0, OpenID Connect (OIDC), and JWTs

OAuth 2.0 handles authorization, OpenID Connect (OIDC) handles authentication, and JSON Web Tokens (JWT) carry claims between parties.

OAuth 2.0 framework (RFC 6749)

OAuth 2.0 lets third-party applications obtain limited access to an HTTP service on behalf of a resource owner.

Core roles

• Resource Owner: The entity (typically a human user) that can grant access to a protected resource.
• Resource Server: The server hosting protected resources (such as an API endpoint).
• Client: The application requesting access to protected resources on behalf of the Resource Owner.
• Authorization Server: The server issuing access tokens to the client after authenticating the Resource Owner and obtaining authorization.

Primary grant types

1. Authorization Code Grant with PKCE (Proof Key for Code Exchange - RFC 7636):
   • Use case: Native apps, Single Page Applications (SPAs), and confidential web applications.
   • Mechanism: Generates a temporary code bound to the request using a code_verifier and code_challenge ($\text{hash}(\text{verifier})$) to block code interception.
2. Client Credentials Grant:
   • Use case: Machine-to-Machine (M2M) communication without user interaction.
   • Mechanism: The client authenticates directly using its credentials (client_id and client_secret, mutual TLS, or private key JWT) to obtain an access token.

OpenID Connect (OIDC)

OIDC adds an identity layer to OAuth 2.0. OAuth 2.0 defines an application's permissions; OIDC verifies the user's identity and authentication method.

• ID Token: A signed JWT issued by the Authorization Server containing claims about the authentication event and user attributes (sub, iss, aud, auth_time).
• UserInfo Endpoint: A protected resource endpoint returning claims about the authenticated user.
• Standard Scopes: openid (required for OIDC), profile, email, address, phone.

JSON Web Tokens (JWT, RFC 7519)

JWTs are compact, URL-safe containers for claims. Each token has three Base64URL-encoded parts separated by dots (.): Header.Payload.Signature.

JWT structure

1. Header: Contains metadata such as the signing algorithm (alg: e.g., RS256, ES256) and token type (typ: JWT).
2. Payload: Holds standard and custom claims:
   • Standard Claims: iss (Issuer), sub (Subject), aud (Audience), exp (Expiration Time), nbf (Not Before), iat (Issued At), jti (JWT ID).
   • Custom Claims: Application-specific roles, permissions, or tenant identifiers.
3. Signature: Cryptographic proof produced using the authorization server's private key over Base64URL(Header) + "." + Base64URL(Payload): $$\text{Signature} = \text{Sign}{K{\text{private}}}(\text{Base64URL}(H) \mathbin{\Vert} \text{"."} \mathbin{\Vert} \text{Base64URL}(P))$$

2. Delegation and context propagation: token exchange and On-Behalf-Of (OBO) flows

In microservices and multi-tier agent systems, services often call downstream systems while preserving the original user's or workload's security context.

OAuth 2.0 token exchange (RFC 8693)

RFC 8693 defines how a client can exchange a token or security context for another token issued by an authorization server.

Key parameters

• grant_type: urn:ietf:params:oauth:grant-type:token-exchange
• subject_token: The token representing the identity requesting access.
• subject_token_type: URI defining the token type (e.g., urn:ietf:params:oauth:token-type:access_token).
• actor_token (Optional): Token representing an intermediary service acting on behalf of the subject.
• requested_token_type: Desired token format.
• audience / resource: Target downstream system for the new token.

Primary use cases

• Cross-Domain Context Propagation: Exchanging an external IdP token (such as Okta) for an internal security token.
• Privilege Reduction (Downscoping): Exchanging a broad access token for one limited to a specific target audience and scope set.

On-Behalf-Of (OBO) flow

Microsoft Entra ID and some enterprise API gateways use the OBO flow for delegation.

Flow

1. Service A receives a request containing a User Access Token.
2. Service A must fetch data from Service B on behalf of that user.
3. Service A submits the User Access Token and its own client credentials to the Token Authority.
4. The Token Authority verifies that Service A can act for the user, then issues a token with its aud set to Service B while keeping the sub assigned to the user.

Delegation vs. impersonation

3. Identity federation

Identity federation lets users or workloads authenticated by one identity provider (IdP) access resources managed by a service provider (SP) or cloud vendor, without creating duplicate accounts. The domains establish cryptographic trust to support this access.

Federation standards

SAML 2.0 (Security Assertion Markup Language)

• Format: XML assertions.
• Common Use: Enterprise SSO and legacy systems.
• Mechanism: Uses HTTP POST bindings or HTTP Redirects to transfer signed XML assertions between an IdP and an SP.

OIDC Identity Federation

• Format: JSON / JWT.
• Common Use: Web apps, mobile applications, and multi-cloud machine-to-machine federation.
• Mechanism: Trust relies on the OIDC Discovery Document (/.well-known/openid-configuration) and JSON Web Key Sets (JWKS), which allow public key verification of signed JWTs.

Federated authentication flow

1. User Request: A user requests a resource on the Service Provider.
2. Redirect to IdP: The SP redirects the user to their designated IdP.
3. Authentication: The user authenticates at the IdP (using MFA, passwordless logins, or passkeys).
4. Token Issuance: The IdP issues a signed SAML Assertion or OIDC ID/Access Token with identity claims (email, groups, roles).
5. Token Validation: The SP verifies the signature against the IdP public key (JWKS), extracts claims, maps them to local permissions, and creates a session.

4. Workload and service identity

Long-lived API keys create security risks in microservices and containerized environments. Workload identity gives running software dynamic, short-lived credentials that can be verified.

SPIFFE / SPIRE: cloud-native identity standards

SPIFFE (Secure Production Identity Framework for Everyone)

SPIFFE is an open-source standard for identifying workloads across cloud and on-premises environments.

• SPIFFE ID: A URI structure that uniquely identifies a workload: $$\text{spiffe://trust-domain/ns/namespace/sa/service-account}$$
• SVID (SPIFFE Verifiable Identity Document): The cryptographic representation of a SPIFFE ID, formatted as an X.509 Certificate or a JWT Token.

SPIRE (SPIFFE Runtime Environment)

SPIRE is the reference implementation of SPIFFE.

• Node Attestation: Verifies the identity of the hosting platform or VM (for instance, evaluating an AWS EC2 instance identity document or Kubernetes node signature).
• Workload Attestation: Identifies running processes on a node using kernel and runtime properties (including Kubernetes namespace, process UID, and container image hash).

Cloud workload identity providers

Cloud platforms can exchange local workload tokens for cloud IAM permissions via OIDC federation, eliminating hardcoded keys:

1. AWS IAM Roles for Service Accounts (IRSA) / EKS Pod Identity: Pods submit a Kubernetes-issued OIDC token to AWS STS (AssumeRoleWithWebIdentity) to receive temporary AWS SigV4 credentials.
2. GCP Workload Identity: Maps Kubernetes or external OIDC tokens directly to Google Cloud IAM Service Accounts.
3. Azure Managed Identities: Assigns Azure resources (VMs, App Services, AKS) an identity managed directly within Entra ID.

5. Agent-to-tool and agent-to-API authentication

AI agents choose tools and call external systems as they work. Security depends on keeping the agent runtime, user credentials, and target APIs separate.

Agent authentication paradigms

1. Inbound Authentication ($\text{User/Caller} \rightarrow \text{Agent}$)

Confirms that the entity calling the agent runtime is authenticated and authorized.

• JWT / OIDC Authorizer: The agent runtime validates incoming JWT tokens against the user IdP discoveryUrl and JWKS endpoint.
• AWS SigV4: Machine callers authenticate to the agent endpoint using signed HTTP requests containing IAM credentials.

2. Outbound Authentication ($\text{Agent} \rightarrow \text{External Tools/APIs}$)

When an agent calls an API or microservice on behalf of a user or system:

• Machine-to-Machine (2-Legged OAuth / API Keys): Fits shared system-level tools. The agent uses its own identity (such as a SPIFFE SVID or IAM role).
• On-Behalf-Of User (3-Legged OAuth): Fits personal data operations (such as reading a user's repository). The agent uses a token bound to both the user context and the required tool scopes.

Security patterns for AI agents

• Token Vault Isolation: Store user OAuth refresh tokens and API keys in dedicated key management vaults (such as AWS KMS-encrypted stores). The LLM processes tool references rather than seeing raw secrets.
• Just-In-Time (JIT) & Scoped Access: Generate short-lived tokens tailored to the specific tool action, preventing a compromised call from abusing wider access rights.
• Policy Enforcement: Place policy evaluation engines (Open Policy Agent, Cedar) between the LLM tool selector and the outgoing API call to inspect arguments before execution.
• Model Context Protocol (MCP) Auth: Use standardized protocol headers where tool servers authenticate agent connections and pass identity context.

6. Multi-cloud AI agent security frameworks (AWS, Azure, GCP)

Cloud providers secure agent workflows with identity management, credential vaults, execution sandboxes, and policy controls.

6.1 Amazon Bedrock AgentCore

Amazon Bedrock AgentCore provides managed infrastructure for enterprise agents, including identity, execution sandboxes, tool integration, and monitoring.

Key Components

1. AgentCore Identity: Manages credentials, identity lifecycle, and delegation flows.
   • Assigns each agent a unique Amazon Resource Name (ARN).
   • Includes a Token Vault backed by AWS KMS to store OAuth tokens, API keys, and secrets.
   • Uses the GetWorkloadAccessTokenForJWT API to derive user context from iss + sub claims and issue scoped workload tokens.
2. AgentCore Runtime: Isolates execution within serverless MicroVMs hosting agent logic and custom tools.
3. AgentCore Gateway: Connects agents to tools and Lambda functions, handling token injection and API formatting.
4. Cedar Policy Engine: Runs policy checks before tool invocation (such as verifying transaction limits stay below a threshold: $<$1{,}000$).

6.2 Microsoft Azure: Entra Agent ID and Azure AI Agent Service

Microsoft Entra ID gives agents dedicated identities that work with Azure AI Agent Service and Azure AI Foundry.

Architecture Features

1. Microsoft Entra Agent ID:
   • Uses dedicated agent identities set up as specialized Service Principals built from an Agent Identity Blueprint.
   • Separates the agent identity from the underlying VM or container identity.
   • Emits tokens containing unique appId and objectId fields for auditing in Sign-in and Audit Logs.
2. Federated Identity Credentials (FIC) Exchange:
   • Connects compute-managed identities (such as Azure Container Apps) to Agent Identity Blueprints without shared secrets.
   • Processes request local tokens via IMDS at 169.254.169.254 and exchange them for agent-scoped Entra access tokens.
3. Execution Modes:
   • Delegated (On-Behalf-Of User): Runs interactive tasks using tokens where sub represents the user and act represents the Entra Agent ID.
   • Autonomous Agents: Runs non-interactive tasks using agent-specific tokens assigned through Azure RBAC or data-plane roles.
4. Governance and Protection:
   • Runtime Guardrails: Filters prompts, tool calls, and completions to block injection and data leak attempts.
   • Microsoft Purview DSPM for AI: Applies Data Security Posture Management, sensitivity labels, and DLP rules to agent interactions.
   • Defender for AI: Flags unusual API activity, prompt attacks, and token misuse.

6.3 Google Cloud Platform: Vertex AI and SPIFFE-based agent identity

Google Cloud uses SPIFFE-based identities with Vertex AI Agent Builder, Vertex AI Reasoning Engine, and the Agent Development Kit (ADK) to secure agent operations.

Architecture Features

1. SPIFFE Cryptographic Identity:
   • Deployed agents automatically receive a cryptographic identity following the SPIFFE standard.
   • Identities are issued as short-lived X.509 certificates by GCP's control plane and rotate every 24 hours.
2. mTLS and DPoP (Demonstrating Proof-of-Possession):
   • Calls to GCP APIs enforce Mutual TLS (mTLS) tied to the agent's X.509 certificate.
   • Cross-gateway calls use DPoP (RFC 9449) headers to bind tokens cryptographically and block replay attacks.
3. Agent Identity Auth Manager:
   • Functions as a credentials vault and authentication broker for tool calls.
   • Manages 2-legged OAuth (M2M), 3-legged OAuth (user delegation via refresh tokens), and API keys.
   • Resolves tool references server-side so secret keys stay out of LLM contexts.
4. Perimeter Controls:
   • VPC Service Controls (VPC-SC): Restricts API calls (agentidentity.googleapis.com) to authorized network perimeters and Restricted VIPs (restricted.googleapis.com).
   • Principal Access Boundaries (PAB): Restricts agent access to targeted cloud resources regardless of inherited IAM permissions.

6.4 Multi-cloud agent security matrix

7. References & Source Specifications

Authorization and token standards (IETF RFCs)

• RFC 6749: The OAuth 2.0 Authorization Framework (IETF RFC Standard)
• RFC 7636: Proof Key for Code Exchange (PKCE) by OAuth Public Clients (IETF RFC Standard)
• RFC 7519: JSON Web Token (JWT) (IETF RFC Standard)
• RFC 8693: OAuth 2.0 Token Exchange (IETF RFC Standard)
• RFC 9449: OAuth 2.0 Demonstrating Proof-of-Possession (DPoP) (IETF RFC Standard)
• OpenID Connect Core 1.0: OpenID Connect Core Specification (OpenID Foundation)

Workload identity and cloud federation specifications

• SPIFFE Standards: Secure Production Identity Framework for Everyone (SPIFFE) Specification (CNCF Graduated Project)
• SPIRE Runtime Environment: SPIFFE Runtime Environment Architecture (CNCF Project Documentation)
• AWS IAM Web Identity Federation: Using Web Identity Federation with AWS STS (AWS IAM Documentation)

AWS, Azure, and GCP agent security frameworks

• AWS AgentCore Documentation: Amazon Bedrock AgentCore Developer & Security Guide (AWS Official Documentation)
• AWS News Blog: Introducing Amazon Bedrock AgentCore Identity: Securing Agentic AI at Scale (AWS Official Technical Blog)
• Microsoft Learn: Securing Azure AI Agents: Identity, Access Control, and Guardrails (Microsoft Official Documentation)
• Microsoft Entra Agent ID: Calling Azure Services from an AI Agent Using Entra Agent ID (Microsoft Technical Guide)
• Google Cloud IAM Docs: Agent Identity Overview & Security Governance (GCP Official Documentation)
• Model Context Protocol (MCP): Anthropic Model Context Protocol Specification (Anthropic Open Standard)

Architectural guidance

Use OIDC with PKCE for human identity flows. For service-to-service calls, use SPIFFE/SPIRE or cloud workload identity federation. Replace hardcoded API keys with short-lived tokens from OAuth Token Exchange (RFC 8693) or cloud OIDC federation.

Keep raw credentials, API keys, and user tokens out of LLM prompts. Store them in an isolated token vault, such as AWS AgentCore Identity, Azure AI Foundry Vault, or GCP Agent Identity Auth Manager. Give each agent a dedicated identity, such as Microsoft Entra Agent ID, GCP SPIFFE Agent Identity, or an AWS Agent ARN, rather than sharing a host compute identity among agents.

Pass user identity down the call stack with On-Behalf-Of (OBO) flows that track iss, sub, and act. Use cryptographic token binding with mTLS or DPoP to prevent replay attacks. Combine serverless sandboxing, policy engines such as Cedar, OPA, or GCP PAB, and runtime guardrails to restrict tool calls independently of LLM output.