HashiCorp Vault integration
Vault provides enterprise-grade secrets management with security guarantees that meet the requirements of regulated industries.Why Vault?
Encryption everywhere
Access control
Audit logging
Dynamic secrets
Vault architecture in MagOneAI
MagOneAI integrates with Vault at multiple levels:The three-tier credential system
MagOneAI manages three distinct types of credentials, each with different lifecycle and access patterns.1. Platform credentials
What they are: API keys and service credentials needed by the platform itself to function. Examples:- OpenAI API keys for GPT-4 access
- Anthropic API keys for Claude access
- Database connection strings
- Email service credentials (SendGrid, Postmark)
- Infrastructure service credentials
secret/platform/
Lifecycle:
- SuperAdmin creates a provider in Admin Portal (e.g., “OpenAI Production”)
- SuperAdmin enters the API key or selects a Vault path
- Platform stores the reference (e.g.,
vault:secret/platform/openai/api-key) - When an agent uses GPT-4, the platform retrieves the key from Vault at runtime
- The key is injected into the API call and never logged or stored
2. User tokens
What they are: OAuth tokens that allow MagOneAI to act on behalf of individual users when calling tools. Examples:- Google OAuth tokens for Gmail, Calendar, Drive access
- Microsoft OAuth tokens for Outlook, Teams, OneDrive access
- Slack OAuth tokens for sending messages
- GitHub OAuth tokens for repository access
secret/users/{user_id}/
Lifecycle:
- User initiates OAuth flow (e.g., “Connect Google Account” in Studio)
- User consents to requested scopes in Google’s OAuth screen
- MagOneAI receives access token and refresh token
- Tokens are stored in Vault at
secret/users/{user_id}/google - When an agent sends an email via Gmail, MagOneAI retrieves the user’s token
- Token is injected into the MCP connection and used to authenticate the Gmail API call
3. MCP connections
What they are: Active tool connections that combine platform credentials and user tokens to enable agent tool use. Examples:- Gmail connection using a user’s OAuth token
- OpenAI connection using a platform API key
- Database connection using platform credentials and user identity
- Agent execution requires calling a tool (e.g.,
gmail_send) - Platform identifies that the tool requires a user OAuth token
- Platform retrieves the executing user’s Google OAuth token from Vault
- Platform creates an MCP connection with the token injected
- Tool executes with the credential
- Connection is closed and credential is not retained
Secret reference syntax
MagOneAI uses a prefix-based syntax to distinguish between different secret sources. This allows flexibility in deployment while maintaining clear semantics.Reference types
- vault: prefix
- env: prefix
- Plain name
vault:secret/path/to/secretUsage: Production deploymentsExample: vault:secret/platform/openai/api-keyBehavior:- Application retrieves the secret from HashiCorp Vault at runtime
- Requires Vault to be configured and accessible
- Provides encryption, access control, and audit logging
- Supports secret rotation without restart
vault: references in production. This is the secure, auditable, enterprise-grade approach.Configuring Vault references
When configuring a provider in the Admin Portal:Navigate to Providers
Create or edit a provider
Enter the Vault path
vault:secret/platform/openai/api-keySave the configuration
Runtime secret injection
Understanding how secrets flow from Vault to agent executions is crucial for appreciating the security model.Example: Agent sends an email via Gmail
Let’s trace how credentials flow when an agent sends an email:Workflow execution starts
Agent decides to use the gmail_send tool
gmail_send tool from its available tools.Platform identifies required credentials
gmail_send requires a Google OAuth token scoped to Gmail access.Platform retrieves user's OAuth token from Vault
secret/users/{user_id}/google from Vault.Platform creates MCP connection
Agent calls the tool
gmail_send with parameters: recipient, subject, body. The OAuth token is not visible to the agent.MCP server authenticates with Gmail
Connection is closed
- The OAuth token is retrieved from Vault only when needed
- The token exists in memory only during execution
- The agent never sees or has access to the token
- The token is not logged in execution history or audit logs
- If the token has been revoked, the execution fails immediately (no retry with cached credentials)
Example: Agent uses OpenAI GPT-4
Let’s trace credential flow for an LLM API call:Agent execution requires LLM inference
Platform identifies the provider
provider: openai and model: gpt-4.Platform retrieves the provider configuration
api_key: vault:secret/platform/openai/api-key.Platform retrieves the API key from Vault
secret/platform/openai/api-key from Vault.Platform makes OpenAI API request
Authorization header of the HTTPS request to OpenAI’s API.Response is returned
- The API key is retrieved fresh from Vault for each request (with caching for performance)
- If the key in Vault is rotated, the next request uses the new key
- The key is never written to logs, execution history, or audit trails
- The key is transmitted only over TLS-encrypted connections
Secret rotation
One of Vault’s key advantages is enabling secret rotation without service downtime. MagOneAI is designed to support this.Rotating platform credentials
To rotate an API key (e.g., OpenAI API key):Generate a new API key
Update the secret in Vault
Verify the new key works
Revoke the old key
Rotating OAuth tokens
OAuth tokens are rotated automatically by MagOneAI:- When the platform retrieves a token, it checks the expiration timestamp
- If the token expires within the next hour, the platform uses the refresh token to request a new access token
- The new access token and refresh token are stored in Vault, replacing the old ones
- The execution proceeds with the fresh token
Rotation audit trail
All secret accesses are logged by Vault:- Secret path accessed
- User or service that accessed it
- Timestamp and source IP
- Whether the access was allowed or denied
vault: references for credentials. The env: prefix is provided for development convenience but lacks the security guarantees of Vault — including encryption, access control, audit logging, and zero-downtime rotation.Vault configuration and deployment
MagOneAI requires a HashiCorp Vault instance to be deployed and accessible. You have several options:Self-managed Vault
Deploy your own Vault cluster for maximum control:- Advantages: Full control over encryption keys, audit logs, and access policies. Integrate with existing Vault deployments.
- Requirements: Vault 1.11+ running in HA mode (recommended for production). Network connectivity from MagOneAI to Vault.
- Configuration: Provide Vault address and authentication token in MagOneAI’s environment configuration.
HashiCorp Cloud Platform (HCP) Vault
Use HashiCorp’s managed Vault service:- Advantages: No infrastructure to manage, automatic updates, built-in HA and backups.
- Requirements: HCP account and network connectivity to HCP Vault.
- Configuration: Provide HCP Vault address and authentication token in MagOneAI’s configuration.
Vault agent for authentication
For production deployments, use Vault Agent to manage authentication:- Deploy Vault Agent as a sidecar or on each host
- Configure Vault Agent with auto-auth (Kubernetes, AWS, Azure, etc.)
- Vault Agent maintains a fresh Vault token and exposes it to MagOneAI
- MagOneAI reads the token from a local file (automatically refreshed by Vault Agent)
Security best practices
Always use vault: in production
env: prefix or direct secret values in production deployments. Vault provides encryption, access control, and audit logging.Scope Vault policies narrowly
Enable Vault audit logging
Rotate secrets regularly
Use dynamic secrets where possible
Monitor for unauthorized access
Troubleshooting
”Unable to retrieve secret from Vault”
Cause: The platform cannot connect to Vault or the secret path doesn’t exist. Solutions:- Verify Vault is accessible from the MagOneAI platform (check network connectivity)
- Verify the secret exists at the specified path using
vault kv get secret/path - Check that the platform’s Vault token has permission to read the secret path
- Review Vault audit logs to see if access was denied
”OAuth token expired”
Cause: The refresh token expired or was revoked, preventing automatic token refresh. Solutions:- User must re-authenticate via the OAuth flow in Studio settings
- After re-authentication, the new token is stored in Vault and the error resolves
”Secret rotation not taking effect”
Cause: Caching may delay the use of the updated secret. Solutions:- Wait up to 60 seconds — the platform caches Vault secrets briefly for performance
- Restart the platform if immediate rotation is critical (though this should not be necessary)