How to build an AI agent that manages its own API keys

How do I build an AI agent that manages its own API key? The question usually surfaces at 2am, when a production agent calls a third-party API with a key that expired six hours earlier. The agent fails quietly, users see nothing, and you find out at standup.

The short answer is four layers: generate credentials at runtime, store only a hash of them, monitor usage for anomalies and spend, and let the agent remediate inside a policy that caps what it can do on its own. None of it needs exotic infrastructure. The rest of this article is how each layer works and where they usually break.

The stakes are not hypothetical. On 1 February 2026, researchers at Wiz found an exposed Moltbook database holding roughly 1.5 million API credentials belonging to AI agents, reachable because a Supabase key sat in client-side JavaScript. In December 2024, a single compromised BeyondTrust API key let an attacker bypass authentication and reach US Treasury workstations, one of seventeen affected customers of the same service. In both cases the failure was not that agents used API keys. It was that the keys were long-lived, broadly scoped and stored somewhere they could be read.

The four layers, and why conflating them fails

Key generation is how the agent obtains a credential at task start. Secure storage is where that credential lives between uses. Usage monitoring is how the agent notices anomalies or an approaching limit. Autonomous remediation is what it does about that, rotate, revoke or top up, without waiting for a human.

Each layer has its own failure mode, which is exactly why they should be designed separately. Weak storage exposes credentials even when generation is sound. Missing monitoring means the agent cannot tell that its key leaked into a log or triggered a burst of 401s. Remediation without a spend policy turns an automated top-up into runaway funding.

A static, long-lived key is a structural problem because its blast radius is unbounded from the moment it is issued. A key sitting in a config file, a model context window or a CI log stays valid until a person revokes it. The architecture goal is the opposite: a credential generated per session or per task, scoped to exactly what the agent needs, expiring on its own.

Scope before you generate. Decide which endpoints, which model routes and which spend limits apply. A key that can spend an entire gateway balance is not the same object as a key that can call two models up to five dollars a day. Least privilege is the starting constraint here, not a hardening step you add later.

How to build an AI agent that manages its own API key: runtime generation and storage

The correct pattern is runtime generation, not deploy-time secrets. The agent requests a credential at task start from a secrets manager or a gateway admin API, uses it for the duration of the task, and revokes it on clean shutdown. Each session starts fresh, and no long-lived key waits in an environment variable to be leaked.

Three storage tools dominate production agent workloads, and each fits a different deployment context.

HashiCorp Vault

Vault issues dynamic credentials with a TTL and revokes them automatically when the lease expires. The agent authenticates, requests a credential for its role, uses it, and Vault cleans up. This is the closest match to how agents actually run, which is discrete bounded tasks rather than a permanent process.

AWS Secrets Manager

Secrets Manager centralizes storage with scheduled automatic rotation, and the schedule can be set in hours rather than days for high-churn secrets. It fits workloads already inside AWS, where workload identity comes free from instance profiles or ECS task roles and authorization is expressed as IAM policy.

Doppler

Doppler favors runtime injection into ephemeral workloads. Secrets are requested when the workload starts and discarded when it ends. This suits containerized agents that want credentials as environment variables at startup rather than fetched mid-execution.

The workflow is the same across all three: authenticate the workload identity, authorize by policy, receive a short-lived secret, use it, let it expire.

Store only a hash of the key on the server side. Show the raw key exactly once at creation and keep nothing but its digest afterward. If someone exfiltrates the keys table they get digests, not usable credentials. Most teams skip this because it adds a step at creation time, and that one step is the difference between a contained database breach and a full credential compromise. It is what we do on ApexApi: keys are stored as SHA-256 hashes and the raw value is displayed once and never again.

Delegation patterns: brokers, OAuth, and KMS

The centralized broker pattern puts an internal service between the agent and any third-party credential. The agent calls the broker, the broker holds the credentials and makes the outbound call, and auth logic, rate limiting and logging all live in one place. Credentials never leave the broker, which is the real security gain.

The tradeoff deserves to be said plainly, because your security team will ask: the broker becomes both a single point of failure and a high-value target. Compromise it and every integration it holds is exposed at once. That is an acceptable trade when the broker is small, audited and hard to reach, and a bad one when it grows into a general-purpose internal proxy.

OAuth client credentials is the right pattern for machine-to-machine access with no user delegation involved. The agent authenticates as itself with a client ID and secret, receives a short-lived access token, and attaches it to downstream calls. Token exchange goes further: the agent presents one credential and receives a downscoped token bound to a specific audience, so it never carries a high-privilege credential across a trust boundary. The cost is configuration surface, because issuers, audience validation, expiry and refresh all have to be right.

For agents handling sensitive data, KMS integration keeps raw key material out of the agent's memory entirely. The agent authenticates to KMS, requests an operation, and uses the result without the key material ever crossing the HSM boundary:

import boto3

s3 = boto3.client('s3')
s3.put_object(
    Bucket='my-bucket',
    Key='agent-output.txt',
    Body=b'Sensitive data',
    ServerSideEncryption='aws:kms',
    SSEKMSKeyId='arn:aws:kms:us-east-1:123456789012:key/your-key-id',
)

Azure Key Vault and Google Cloud KMS follow the same model. Authenticate the workload, authorize by policy, receive protected material. The SDK calls differ and the architecture does not.

Rotation and monitoring without downtime

Three signal categories are worth acting on automatically. Volume anomalies, meaning a request rate far above the agent's normal baseline over a short window. Geographic anomalies, meaning calls from a region the agent has never used. Error pattern shifts, meaning a sudden run of 401s or 429s where there were none. All three are cheap to collect from structured logs, and all three are more useful pointed at a revocation path than at a dashboard nobody is watching at 2am.

Spend is the fourth signal and the one agents can read most directly. On ApexApi every response carries the exact dollar cost of that call in the X-ApexApi-Cost header, to eight decimal places, including on streaming responses. An agent that reads that header on every call has a running cost total without polling anything, which is what makes a threshold check cheap enough to run continuously.

Rolling rotation with an overlap window is the detail most guides skip. Generate the new key. Update the agent's credential reference. Leave both keys valid for a short window while in-flight requests finish on the old one. Then revoke the old key. For a production agent that window is usually seconds to minutes. Skip it and rotation becomes an outage, which is why so many teams quietly stop rotating after the first attempt.

Common cadences are 90 days for service-to-service keys and 30 days or less for high-privilege credentials, with immediate rotation after any suspected exposure. Immediate has to mean one programmatic call, not a runbook. If your credential issuer cannot revoke instantly through an API, that is an architectural constraint to solve before it becomes an incident rather than during one. The triggers that should force immediate rotation: suspected log exposure, abnormal agent behavior, employee offboarding, and a secret scanner finding the key in a repository.

Autonomous top-up, and the guardrails it needs

The balance-check loop has three design decisions. What triggers the check, whether that is elapsed time, request count or a balance threshold. What the top-up increment is. And how to handle the race where two agent threads both see a low balance at the same time.

That race is the one that bites in production. Threads A and B both read a low balance, both fire a top-up, and the account is funded twice. The fix is a distributed lock or an atomic database update, combined with an idempotency key on the top-up request so the provider processes exactly one operation even if both requests arrive.

Building all of this from scratch means writing a secrets broker, a balance service and a payment automation layer. On ApexApi three of those pieces already exist at the gateway, and it is worth being precise about which lives where.

Key generation is one unauthenticated HTTP call. POST /agent/register with {"type": "anonymous"} returns a working ak- key and a claim token, with no dashboard, no card and no person in the loop. Registrations are capped per IP per day.

Funding is POST /agent/fund. The agent names a whole-dollar amount and gets back a USDC deposit address on Base. It sends the funds from its own wallet, and the balance is credited when the deposit settles on chain:

# 1. Get a key. No human, no card.
curl -s -X POST https://api.apexapi.dev/agent/register \
  -H 'Content-Type: application/json' \
  -d '{"type":"anonymous"}'

# 2. Read the balance whenever the loop wants it.
curl -s https://api.apexapi.dev/agent/account \
  -H "Authorization: Bearer $APEXAPI_KEY"

# 3. Top up from the agent's own USDC wallet on Base.
curl -s -X POST https://api.apexapi.dev/agent/fund \
  -H "Authorization: Bearer $APEXAPI_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"amount_usd":50}'

An agent already connected over MCP can skip the second call and use the get_balance tool instead, since it is talking to the gateway anyway. The MCP integration reference has the full tool list. Pricing is real dollars per call with no invented credit currency in between, which is on the pricing page.

Two things we deliberately do not do, so you can plan around them. We do not detect anomalies on your behalf, so the monitoring layer described above stays your code. And revocation, while instant, is a dashboard action rather than a public API call today, so an agent cannot revoke its own key programmatically. If your rotation design depends on a single programmatic revoke, that gap is currently yours to fill. What each key does carry is its own daily and monthly spend limit, a model allowlist and an expiry date, which is the scoping layer from earlier expressed as configuration. Those are covered in the authentication docs.

Autonomous funding still needs limits around it. The agent needs a funded wallet, a hard ceiling on any single top-up, a maximum top-up frequency, and audit logs a human can review after the fact. The point is to take the human out of the approval loop for routine refills, not out of the visibility loop. The same discipline applies to team budgets more broadly, which we covered in controlling AI API costs across a team.

Audit records for autonomous credential operations should capture the agent ID, the triggering principal, the session ID, a credential reference that is never the raw secret, the scope granted, the token TTL, who or what initiated the rotation, and the policy decision. A security team needs to answer four questions from those logs: who initiated it, which agent executed it, which credential changed, and whether the old credential was actually invalidated.

A security checklist before you ship

Run through each item before the agent reaches production.

• No raw keys in model context windows or logs. A key that appears in a prompt will also appear in completions, caches and provider-side logs.
• All secrets fetched at runtime, not baked at build time. Your image and your repository should contain no credentials at all.
• Rotation schedules configured and tested, not merely planned. An untested rotation is an untested outage.
• Anomaly signals wired to something that can revoke, so a detection is an action rather than a notification.
• Top-up policy capped with a hard maximum amount and a maximum frequency.
• Audit logs retained for a defined period, with the full field set above.

The gap between working in development and defensible in production is almost always these six items.

Build the architecture before the incident

The agent that failed quietly at 2am did not need unusual infrastructure. It needed a short-lived key generated at task start, a monitoring loop wired to a revocation path, a rotation schedule with an overlap window, and a top-up that did not wait on a human. Every one of those primitives exists today in Vault, Secrets Manager, OAuth flows and, for the gateway side of it, in an API call.

The wrong starting point is a hardcoded key in an environment variable, and most production agents are still there. If you have been asking how to build an AI agent that manages its own API key, this is not a capability to wait for. It is a design decision you can make this week.

Read the quickstart to route your first request through the gateway, or browse the model catalog to see what an agent gets access to on one key.