Stop Putting API Keys in Your Agent's .env File

Hasnain Arif — Wed, 19 Aug 2026 06:09:02 +0000

Open any repo with an AI agent in it and you'll find the same thing nine times out of ten: a .env file with an OpenAI key, a GitHub token, maybe a database URL, all long-lived, all scoped to basically everything, all sitting in plaintext on disk.

This works fine in a demo. It's also exactly the pattern that turns a single leaked file, a compromised dependency, or a prompt-injected tool call into total account takeover, because the credential the agent is holding doesn't expire, doesn't know what task it's for, and can usually do a lot more than the task actually needs.

The fix isn't "better secrets management." It's not treating the agent as something that holds credentials at all. Below is the pattern that's actually converging across MCP, Auth0, WorkOS, and a few other places building this right now, plus a minimal implementation you can steal.

Why your current setup is the problem, not a workaround away from it

A static API key answers one question: is the bearer allowed to do this category of thing, forever, until someone remembers to rotate it. That's a bad shape for an agent, because an agent isn't one actor doing one job. The same agent process might read a customer record for one user, then modify a deployment config for a completely different user, thirty seconds later, using the same credential the whole time.

Give that credential broad scope once, and every one of those very different actions is now authorized by the same blanket permission. If the agent gets manipulated into doing something it shouldn't — a prompt injection, a bad tool call, a hallucinated plan — the credential doesn't know the difference. It was never scoped to the task in the first place.

The fix is to stop giving the agent a credential at all, and instead give it a way to ask for one, just before it needs it, scoped to exactly that action.

The decision tree

Before you touch any code, figure out which of these your agent actually is, because it changes the whole flow:

Does the agent act on behalf of a specific logged-in user?
├── YES → Authorization Code + PKCE
│         (agent inherits a narrow, user-consented scope)
│
└── NO → Is it a background job / daemon / pipeline with no user in the loop?
          ├── YES → Client Credentials Grant
          │         (agent authenticates as itself, gets a short-lived token)
          │
          └── UNCERTAIN → Does it ever touch a specific user's data mid-task?
                    ├── YES → treat as user-delegated, use token exchange
                    └── NO  → Client Credentials, narrowest scope you can define

Most agent architectures actually need both at different points — client credentials for the agent's own background identity, and token exchange whenever it needs to act as a specific user for one call.

Pattern 1: Client credentials, done right

This is the baseline for an autonomous agent with no user in the loop. The agent authenticates as itself and gets a token that dies fast.

import time
import httpx

class AgentTokenClient:
    def __init__(self, token_url, client_id, client_secret):
        self.token_url = token_url
        self.client_id = client_id
        self.client_secret = client_secret
        self._cached = None  # (token, expires_at, scope)

    def get_token(self, scope: str) -> str:
        if self._cached and self._cached[2] == scope and self._cached[1] > time.time() + 5:
            return self._cached[0]

        resp = httpx.post(self.token_url, data={
            "grant_type": "client_credentials",
            "client_id": self.client_id,
            "client_secret": self.client_secret,
            "scope": scope,
        })
        resp.raise_for_status()
        data = resp.json()
        expires_at = time.time() + data["expires_in"]
        self._cached = (data["access_token"], expires_at, scope)
        return data["access_token"]

Two things worth doing that people skip: request the narrowest scope string that covers the actual call you're about to make (not "crm:*", but "crm:read:invoices"), and set the TTL as low as your workflow tolerates. Five to fifteen minutes for anything sensitive, an hour at most for read-only calls. There's no refresh token in this flow on purpose — if the token expires, the agent just re-authenticates. That's a feature, not friction.

Pattern 2: Token exchange for "acting as this specific user, right now"

This is the one most agent codebases skip entirely, and it's the one that actually matters once your agent does anything on behalf of different users.

The idea, from RFC 8693: your agent holds a base token that proves who the agent is, and exchanges it for a narrower, audience-restricted token that proves what this specific call is allowed to do, for this specific user, right now.

def exchange_for_scoped_token(base_token: str, target_resource: str, action: str) -> str:
    resp = httpx.post(TOKEN_EXCHANGE_URL, data={
        "grant_type": "urn:ietf:params:oauth:grant-type:token-exchange",
        "subject_token": base_token,
        "subject_token_type": "urn:ietf:params:oauth:token-type:access_token",
        "resource": target_resource,
        "scope": action,          # e.g. "invoices:refund"
    })
    resp.raise_for_status()
    return resp.json()["access_token"]

The payoff: if this narrow token leaks, the blast radius is one action, on one resource, for a window measured in minutes — not the agent's entire standing access to everything it's ever touched.

Pattern 3: The vault broker, so the agent never sees a raw secret

The cleanest version of this removes the agent from the credential-handling business entirely. The agent doesn't request a token from an auth server directly — it asks a broker for permission to do something, and the broker injects the credential on the way out to the actual API call.

class CredentialBroker:
    def __init__(self, vault_client):
        self.vault = vault_client

    def authorized_call(self, agent_identity: str, action: str, api_call):
        # 1. Policy check — is this agent allowed to do this, right now?
        if not self.policy_allows(agent_identity, action):
            raise PermissionError(f"{agent_identity} not authorized for {action}")

        # 2. Mint a scoped, short-lived token for exactly this action
        token = self.vault.issue_token(scope=action, ttl_seconds=300)

        # 3. Make the call, inject the credential here, never hand it to the agent
        try:
            return api_call(token)
        finally:
            self.vault.revoke(token)  # belt and suspenders

The agent's code just calls broker.authorized_call("refund-agent", "invoices:refund", do_refund) and never touches a credential at all. If the agent's process gets compromised — prompt injection, malicious tool output, whatever — there's nothing to steal, because nothing long-lived was ever there.

What MCP already gets right here

If you're building on Model Context Protocol, some of this is handled for you by design. MCP's authorization spec deliberately treats the MCP server as an OAuth resource server, not an authorization server — meaning the server that handles your tool calls isn't the one deciding who's allowed to call them. That job belongs to a dedicated identity provider, and the MCP server's only responsibility is validating the token it's handed.

That split matters more than it sounds. It means you can swap out or upgrade your auth provider without touching every MCP server you run, and it means tool-level authorization decisions live in one place instead of being reimplemented inconsistently across every integration you build.

If you're rolling your own agent-to-tool protocol instead of MCP, this is worth copying even without the rest of MCP: keep "can this token do this" completely separate from "what does this tool do."

Where this still breaks

Being honest about the gaps, because this pattern isn't a finished solution yet:

Multi-tenant isolation. If your agent serves multiple organizations, every token needs the tenant ID baked in and checked at every hop — an agent from Org A presenting a token that happens to also work against Org B's data is a real, recurring failure mode.
Revocation lag. Short TTLs help, but if you revoke an agent's standing access mid-task, in-flight short-lived tokens it already grabbed can still be valid until they expire on their own.
"Who approved this scope" governance. The mechanism above handles issuance cleanly. It says nothing about who decided this agent should be allowed to request invoices:refund in the first place, or whether that decision gets reviewed six months later. That's policy work, not code, and most teams skip it because it's the boring part.
SDK friction. A lot of LLM provider SDKs still assume one static key at initialization with no clean hook for mid-session credential rotation. You'll end up wrapping the client yourself more often than you'd like.

The one-line version

An agent is not a user and it's not a static service account — it's a new kind of actor that needs its own identity, its own narrowly scoped credentials, and a credential lifetime measured in minutes, not months. If your agent's .env file has anything in it that doesn't expire on its own, that's the thing to fix this week, before it's the thing in next month's incident report.

DEV Community: Hasnain Arif