Secure AI agent authentication using HashiCorp Vault dynamic secrets

Authors: Simon Lynch and Ravi Panchal

This validated pattern enables organizations to securely integrate AI agents with HashiCorp Vault Enterprise (or HCP Vault Dedicated) for dynamic secrets management. Standard OAuth 2.0 authentication and token exchange enables tools to securely authenticate with HashiCorp Vault with user attribution and comprehensive audit trails, while enforcing role-based access controls, keeping AI tool usage traceable, compliant, and secure.

As an application developer building custom web applications with AI agents, you need a secure way to manage the credentials your agents use to access databases, APIs, and backend services, all without embedding static secrets or losing user attribution.

This validated pattern shows you how to integrate your custom AI web application with HashiCorp Vault for dynamic, user-attributed secrets management. Instead of managing static secrets, your AI agent tool calls can request just-in-time credentials that are automatically scoped based on role based access.

When you integrate AI agents with Vault you gain the following benefits:

• Centralized control: Unified secrets management across all AI agents eliminates operational silos and enforces consistent security policies enterprise-wide.
• Complete auditability: The system logs every secret request, access, and rotation, enabling comprehensive compliance reporting and security monitoring.
• Dynamic secrets: Automated credential lifecycle management with just-in-time provisioning and automatic rotation eliminates credential sprawl and reduces exposure windows.

Better identity management systems reduce business risks by closing security gaps that can lead to regulatory problems. These systems also protect against insider threats by controlling who has access to what and regularly changing security credentials.

These solutions make operations run more smoothly by removing barriers that slow down AI projects and other technology initiatives. Teams spend less time managing passwords and user access because the system handles these tasks automatically. This frees up IT staff to work on more important projects while keeping security strong.

For compliance, these systems help companies meet regulations like the General Data Protection Regulation (GDPR), Health Insurance Portability and Accountability Act (HIPAA), and the EU AI Act. They automatically track who accessed what and when, making it easier to prove compliance during audits. The system stores all this information in one place and allows for efficient searches, which saves time and effort when preparing for regulatory reviews.

The result is a system that improves security, speeds up work processes, and makes compliance easier to manage.

Target audience

This guide references the following roles:

Platform team: Team who manages your organization's platform infrastructure. This may include security, platform.

AI/ML engineer: Someone who develops, deploys, and maintains AI agents and tools that require secure access to external systems and APIs with HashiCorp Vault. These engineers consume Vault-managed secrets through their agent framework of choice

Security engineer: Someone responsible for implementing and maintaining security policies for AI systems, ensuring compliance with regulatory requirements, and monitoring secret access patterns across AI agents and tools.

Prerequisites

Platform operator:

• Privileged access to a Vault Enterprise or HCP Vault Dedicated cluster that grants permissions to create auth mounts, configure auth roles, and create policies.
• Permission to configure and manage application identities in the organization's identity platform, for example, Active Directory or Okta.

AI/ML engineer:

• Permissions to create and deploy AI agents and tools.
• Understanding of tool authentication requirements and downstream API integrations.

Limitations

When integrating HashiCorp Vault into your application architecture, it is crucial to understand the constraints of your chosen Vault secrets engine and design your application to meet your requirements. For example, when using dynamic database credentials you have multiple configuration choices:

• Static roles with rotation: credentials are periodically refreshed, but multiple sessions may share the same credentials. This may blur attribution from an end-to-end traceability perspective.
• Dynamic just-in-time credentials: generated on-demand, provides clear attribution but introduces additional dependency on Vault availability and additional database connections.

Background and best practices

This document presents a validated architecture that defines recommended AI application identity authentication workflows for integrating AI agents and tools with HashiCorp Vault, enabling secure, centralized dynamic secrets management with user attribution through OAuth 2.0 token exchange.

Challenges today

Organizations deploying AI agents face critical technical gaps in authentication and secrets management:

Identity and attribution gap: AI agents lack mechanisms to propagate user identity through execution chains, breaking the link between user requests and downstream service calls, making user-specific permissions and audit trails challenging.

Static credential proliferation: Agents often use long-lived static credentials embedded in configurations that persist indefinitely, require manual rotation, and create an expanding attack surface across multiple agents and tools.

Missing least-privilege enforcement: Without dynamic credential generation, agents operate with fixed, over-privileged permission sets that violate zero-trust principles by granting maximum permissions for any potential operation.

Decentralized secrets architecture: No centralized secrets management exists for AI agents, resulting in inconsistent security policies, fragmented audit logs, and no unified credential lifecycle management.

Compliance gaps: Absence of user attribution and comprehensive logging makes it challenging to meet compliance and audit requirements.

Validated architecture

The following validated architecture outlines a validated pattern for authenticating users to AI applications and passing user identity through attribution into AI tool authentication flows that leverage HashiCorp Vault for dynamic secrets.

This agentic application architecture delivers a secure and auditable workflow that enables users to interact with resources, such as databases, through an AI-powered interface. It employs modern authentication and authorization mechanisms to tightly control user access, ensuring that all actions performed by the AI agent on behalf of the user are traceable and aligned with the principle of least privilege.

Key components

Microsoft Entra ID: Serves as the trusted identity provider that authenticates users and issues the initial JSON Web Token (JWT), centralizing user management with industry-standard security.

Web UI: User-facing interface for login and interaction with the AI agent. It securely handles the JWT and forwards it to the backend.

AI agent: Core of the agentic flow, powered by a Large Language Model (LLM) to interpret intent and orchestrate tasks. Validates the user token, performs the On-Behalf-Of (OBO) exchange, and decides which tool to invoke. It cannot directly access sensitive resources and only calls the Model Context Protocol (MCP) Server with the delegated identity, isolating the LLM from critical infrastructure.

AI tools (MCP server): Secure execution layer for backend operations. Validates the OBO token, authenticates to Vault, retrieves dynamic credentials, and accesses API/services using dynamic credentials. Encapsulates Vault and API/service logic, blocking arbitrary or unintended operations and allowing only authorized and auditable actions.

HCP Vault: Secrets management service using JWT authentication. Validates the OBO token and issues short-lived, scoped credentials based on user claims, enforcing least-privilege and eliminating static credentials.

API/Service: The protected resource, for example a database, accessed using dynamic Vault-issued credentials. Access is strictly time-bound and permission-scoped, ensuring user actions remain within their authorized role.

This pattern applies to databases or any other protected resource, with Vault enforcing least-privilege, time-bound access.

Detailed authentication flow

This diagram illustrates a secure authentication and authorization flow that integrates an Identity Provider (IdP) with HashiCorp Vault to provide role-based access for an AI agent application.

The process begins when a user accesses the web application, which redirects them to the IdP for authentication and token issuance. The AI agent receives the resulting JWT containing user and group claims, validates it, and exchanges it for an OBO token. The agent then uses this OBO token for tools to authenticate with HashiCorp Vault.

Vault validates the agent tool login through JWT and maps to an appropriate Vault policy based on the group claims, it then issues a Vault token with scoped permissions allowing access to secrets. This token enables the agent to request dynamic just-in-time credentials. This authentication architecture ensures just-in-time credential provisioning for AI agents with complete traceability and user attribution for full auditability and compliance.

This sequence diagram illustrates a complete, secure workflow from user login to receiving an AI-generated response. We break the process down into three main phases: user authentication and agent invocation, secure backend processing, and response delivery.

Phase one: User authentication and agent invocation

This phase covers the user's login process and the initial call to the AI Agent.

In the preceding example, the system captures the user token using an OAuth 2.0 code authorization flow. Code authorization flow provides secure OAuth 2.0 authentication by separating user login from token exchange. Users authenticate with the Identity platform while the application receives tokens through secure back-channel communication using an authorization code to request a user access token. The system invokes the agent passing the user's token as a parameter.

Phase two: Secure backend processing and data retrieval

This phase details how the AI Agent securely orchestrates backend tools to fulfill the user's request. The AI Agent validates the incoming user JWT, then performs an OBO token exchange to create a new token containing both the agent's identity and the user's claims for end-to-end traceability. The agent calls the AI tool with this OBO token, which validates it and authenticates with HashiCorp Vault using JWT authentication. Vault inspects the user's group claims, issues a short-lived auth token, and generates dynamic credentials, for example, database credentials with role-specific permissions. The AI Tool then accesses the API/service using these temporary credentials and returns the results to the agent.

Phase three: Response delivery

This final phase covers how the system returns the result to the user. The AI Tool sends the retrieved data back to the AI Agent, which processes the information and formulates a user-friendly response before sending it to the web application for display to the user.

People and process considerations

Organizational structure: Define clear ownership boundaries between Platform, AI/ML, and Security teams using a RACI matrix for credential lifecycle management. Establish regular cross-team sync meetings and a shared responsibility model where AI teams own functionality while Security owns access policies.

Onboarding and automation: Implement an automated agent onboarding process requiring security review and approval before production deployment. Create standardized Vault policy templates for common patterns and use Infrastructure-as-Code with Git-based workflows for all Vault configurations and policy changes.

Token exchange

Both Entra-ID on-behalf OAuth flow and RFC 8693 token exchange are valid patterns for token exchange, allowing the conversion of user identity to AI agent and downstream tool identity.

The diagram below illustrates the typical token exchange scenario for user attribution to AI agent tools

EntraId on-behalf

Microsoft Entra ID's On-Behalf-Of flow enables an application to acquire tokens for a downstream API by exchanging the user's token with additional scopes, maintaining the user's identity and claims throughout the authentication chain.

Example API calls for EntraID On-behalf

On-Behalf request:

POST https://login.microsoftonline.com/788d8595-3c0f-4d77-beda-ca1bb0715ede/oauth2/v2.0/token HTTP/1.1  
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer  
&client_id=<5c3790ba-90d7-48e .... AGENT APPLICATION ID>  
&client_secret=<7TZ8Q~Ob3xYHwUXMFgZE.... AGENT APPLICATION SECRET>  
&assertion=<eyJ0....USER ACCESS TOKEN>  
&scope=api://6a40d9e9-49b5-415b-91a8-67488d2eeff1/Products.Read  
&requested_token_use=on_behalf_of

Explanation:

Returned JWT:

{  
  "aud": "6a40d9e9-49b5-415b-91a8-67488d2eeff1",  
  "iss": "https://login.microsoftonline.com/788d8595-3c0f-4d77-beda-ca1bb0715ede/v2.0",  
  "iat": 1756175524,  
  "nbf": 1756175524,  
  "exp": 1756180599,  
  "aio": "ARQB6/4ZAAAAjE2dZ6iv5IzEhvW+VyNaPRJ4QEF1dTpFVxZbe3SU4d7LRp8orzopJBz/azG22TYbr45OzEIbkmh+JdSz8bWHNfCnolDVRX27lT8Ysn0wMIpwZphHRmRgoPrCWR7bPQhddlHLV+sb+SQeJFi0CAxstIl1/43BXe+ugZDq7UPNAJw2P2krCqLEC6dwthyAL1Tw38ZFNA7/4X3mDmNo3LCoLGDFQIvlxkFaOx8Ykl+XTBlL0MgOh8SCRFGSroHdr2B5VAWHvry1nAVttNAgYQG5zdfIYes9cnWJbYaInins8rev9hczmZ5kQnhKkGv20cXXMqa4oB6xQhiOs/u+z/mD2WEx88+TKetnYs8c6ewp3gs=",  
  "azp": "5c3790ba-90d7-48e0-ac13-b11cb6631913",  
  "azpacr": "1",  
  "groups": [  
    "8f3b4ca8-b9b4-4d1c-833b-89ebefda3ec8",  
    "caa63053-d98e-40aa-ac05-5bbbed4bd5e0"  
  ],  
  "idp": "live.com",  
  "name": "Some User",  
  "oid": "7051bbb3-5a2a-44bd-b079-4148911e4ab5",  
  "preferred_username": "some.user@business.com",  
  "rh": "1.AUIAlYWNeA88d02-2sobsHFe3unZQGq1SVtBkahnSI0u7_FCADRCAA.",  
  "scp": "Products.Delete Products.List Products.Read Products.Write",  
  "sid": "007dea79-f7f1-4f6e-8312-abc45d6c32f0",  
  "sub": "1LYihzmSVN99ue_DFfYbJ0Ss7MsbF43PAbzXY7FFU0E",  
  "tid": "788d8595-3c0f-4d77-beda-ca1bb0715ede",  
  "uti": "lwiMcyNExEC03QHANpX-AA",  
  "ver": "2.0",  
  "xms_ftd": "jHvrSD71TEQ9qqhAw9iKxl3ZOGLvhyhF2G-5tGfGhV8BYXVzdHJhbGlhZWFzdC1kc21z"  
}

Key fields in returned On-Behalf-Of JWT:

Vault JWT authentication with external group claims

The diagram below outlines the mapping between user identity groups and external groups in HashiCorp Vault. We use this mapping to associate group-based Vault policy based on the exchange token group claims through JWT authentication.

Identity Provider (IDP) configuration - group claims

To enable capture of the users' group claims, you must configure the Identity Provider (IDP) applications to support additional group claims in the returned access token. We map these to role-based policies in HashiCorp Vault using external groups and policies. See the example below for Azure EntraId. Refer to your specific IDP for specific configuration requirements for including group claims in returned access tokens.

Example application with additional group claims

The code block below provides example configuration with an excerpt for application configuration in EntraId using Terraform.

The key item highlighted shows that the system populates the user groups using additional optional claims on the IDP application configuration.

resource "azuread_application" "example_web_app" {  
  display_name     = "ExampleWebApp"  
  sign_in_audience = "AzureADMyOrg"  
  owners           = var.owners  
  tags             = var.tags  
 ...

  optional_claims {  
    access_token {  
      name = "groups"  
    }  
    id_token {  
      name = "groups"  
    }  
  }  
}

Example JWT config for external IDP groups to Vault policies

Below are the key items for ensuring traceability of tool authentication to user identity:

• user_claim maps to the preferred_username, ensuring a unique identity per user
• bound audiences maps to the tool identity in the IDP
• bound claims maps to the authorized part (azp) being the agent identity in the IDP

Review the traceability section below for more detail of Vault traceability end to end in logs.

The code block below provides example configuration for the HashiCorp Vault JWT backend role.

resource "vault_jwt_auth_backend_role" "default" {  
  namespace               = var.namespace != null ? var.namespace : null  
  backend                 = vault_jwt_auth_backend.jwt.path  
  role_name               = "default"  
  role_type               = "jwt"  
  token_no_default_policy = true # Don't assign default policy  
  user_claim              = "preferred_username"  
  groups_claim            = "groups"  
  verbose_oidc_logging    = true  
  token_ttl               = var.token_ttl  
  token_max_ttl           = var.token_max_ttl  
  # Bind to specific audience (client_id of the AI agent tool)  
  bound_audiences = [var.audience_tool_client_id]  
  bound_claims = {"azp" = var.azp_agent_client_id}  
}

# Additional external groups - map Vault groups and policies to EntraId groups  
resource "vault_identity_group" "external_groups" {  
  for_each  = var.external_groups  
  namespace = var.namespace != null ? var.namespace : null  
  name      = each.value.group_name  
  type      = "external"  
  policies  = each.value.policies  
  metadata = {  
    name = each.value.group_name  
  }  
}

resource "vault_identity_group_alias" "external_group_aliases" {  
  for_each       = var.external_groups  
  namespace      = var.namespace != null ? var.namespace : null  
  name           = each.value.alias_name  
  mount_accessor = vault_jwt_auth_backend.jwt.accessor  
  canonical_id   = vault_identity_group.external_groups[each.key].id  
}

Traceability

This section explains how to ensure complete end-to-end traceability of AI agent actions back to the original user identity through audit logs and request correlation across the authentication chain.

Using Vault Correlation-id for user context

To enable user and session traceability, add structured request headers to every Vault request that agents make to the HashiCorp Vault API. When you enable Vault audit devices, these headers record data and let you correlate requests to users, sessions, and services. Include a correlation header X-Correlation-ID with any additional user/session metadata encoded in the value. Ensure header values are consistent and sanitized, with no secrets or Personally Identifiable Information (PII) included. Ensure that you forward audit logs to your Security Information and Event Management (SIEM) system. See logging-request-headers

You can use the /sys/audit-hash endpoint to calculate the hash of the data used by an audit device's hash function and salt. You can use this to search audit logs for a hashed value when you know the original value. See calculate-hash

The following illustrates how a single user request flows end-to-end through a 3-tier agentic application (Web > AI Agent > MCP Server > HashiCorp Vault) while carrying a consistent Correlation ID to support efficient troubleshooting and security forensics.

Web UI:

2025-09-02 08:21:58,035 - INFO - products_web: 45df07b9-bd1d-43b6-897a-3e743c9565fb-Bob - Calling ProductsAgent API with payload: {'prompt': 'list all products'}

AI agent:

2025-09-02 08:22:03,968 -  INFO - products_agent: 45df07b9-bd1d-43b6-897a-3e743c9565fb-Bob - msg: {'text': 'Here is the list of all products:

MCP server:

2025-09-02 08:22:01,390 -  INFO - product_service: 45df07b9-bd1d-43b6-897a-3e743c9565fb-Bob - Fetching products

HCP Vault JWT authentication:

"request": {
   "headers": {
       "x-correlation-id": [
            "45df07b9-bd1d-43b6-897a-3e743c9565fb-Bob"
        ]
   },
   "mount_point": "admin/auth/jwt/",
   "path": "auth/jwt/login",
   "remote_address": "42.61.153.210",
   ...

"response": {
        "auth": {
            "accessor": "hmac-sha256:1bba2226bd34896200d91c3ba14fce27e5252ab462ca52b802416600fa36f5be",
            "client_token": "hmac-sha256:b93075ceec924df49f30fbe028fe33567871d8ea02496ef306468a26825db7a9",
            "display_name": "admin-auth-jwt-bob@hashidemo.onmicrosoft.com",
            "entity_id": "f59c2dd4-a4f3-306c-faa3-f277f078046e",
            "identity_policies": [
                "readwrite"
            ],
            "metadata": {
                "aud": "2a86adc7-f60e-424c-b256-17134f380a9f",
                "name": "Bob",
                "role": "default"
            },
            "policies": [
                "default",
                "readwrite"
            ],

HCP Vault dynamic credentials:

"request": {
    "headers": {
        "x-correlation-id": [
            "45df07b9-bd1d-43b6-897a-3e743c9565fb-Bob"
        ]
    },
    "path": "database/creds/readwrite",
    "remote_address": "42.61.153.210",
    "request_uri": "/v1/database/creds/readwrite"
},

"response": {
    "data": {
        "password": "hmac-sha256:aadbe6710bb9f6a7121eda0383ea715d0084c6e3562cfca2b3a8b10172dd609a",
        "username": "hmac-sha256:07318fc8b181bcfbcff3b5978057e68dc8241e8cf7372091ffb5a9ac3dc80ddb"
    },
    "secret": {
        "lease_id": "database/creds/readwrite/wCELKABKjhQX5IBesaCVx6AF.oOotE"
    }
},
"time": "2025-09-02T00:22:01.42316891Z"

Implementation examples

The following are platform-specific examples to help with understanding some potential real-world scenarios.

AWS Strands

Application components

1. products-web: A Streamlit-based web interface secured with Microsoft Entra ID for OAuth-based authentication and authorization. It securely handles the user login, retrieves JWT access token, and forwards it to the backend.
2. products-agent: A FastAPI service that hosts the AI agent, leveraging the AWS Strands SDK and AWS Bedrock LLM for intelligent task orchestration. It validates the user token, performs the OBO exchange, and decides which tool to invoke.
3. products-mcp: A Model Context Protocol (MCP) server that handles secure database interactions using dynamic credentials. It validates the OBO token, authenticates to Vault using the OBO token, retrieves dynamic database credentials mapped to the user groups policy, and executes database/API queries.

Infrastructure components

1. HCP Vault: Centralized secrets management system with JWT authentication. It validates the OBO token and issues short-lived, dynamic database credentials based on user group claims.
2. AWS DocumentDB: MongoDB-compatible database for storing product data
3. Microsoft Entra ID: Identity provider for authentication and access control.
4. AWS Bedrock: Managed AI service providing access to the foundation LLM models.
5. AWS Infrastructure: Core environment including VPC, security groups, bastion host, and networking.

Authentication and authorization

• The products-web component handles user authentication using Microsoft EntraID.
• Authorization for both the products-agent and products-mcp is strictly enforced, requiring a valid JWT bearer token for access.
• The products-agent expects the initial JWT issued by Microsoft Entra ID, where the subject of the token is the authenticated user.
• The products-mcp, in turn, expects the OBO token generated by the products-agent. This OBO token encapsulates a chained identity: its subject claim identifies the products-agent, while additional claims contain the original user's identity and group memberships. Both the products-agent and the products-mcp validate these tokens..

Key security configurations: From user JWT to dynamic credentials

Please refer to the GitHub repository for further details. The repository contains Terraform code for setting up the described infrastructure and deploying the applications.

Conclusion

This validated pattern enables organizations to securely deploy AI agents at scale by combining OAuth 2.0 token exchange with HashiCorp Vault's dynamic secrets management. The architecture eliminates static credential risks while ensuring complete user attribution and audit trails for all AI agent activities. By providing just-in-time credential provisioning with role-based access controls, organizations can accelerate AI initiatives while meeting stringent compliance requirements, including GDPR, HIPAA, and the EU AI Act. This transforms AI agent deployment from a security concern into a competitive advantage.

Related resources

• Microsoft Entra ID OAuth 2.0 On-Behalf-Of flow
• IBM Security Verify OAuth 2.0 Token Exchange
• RFC 8693: OAuth 2.0 Token Exchange
• HashiCorp Vault JWT/OIDC Auth Method
• Terraform Vault Provider: Identity Group Alias Resource
• HashiCorp Vault Audit Logging: Request Headers