Ephemeral Credentials and Zero-Trust AI: Rethinking API Security

This article was revised in October 2026: an earlier version attributed scoped tokens, audit lineage and bulk revocation to perishable, which it does not implement.

Somewhere in your infrastructure, an AI agent holds an API key. It might be an OpenAI key, an Anthropic key, a database connection string, or a cloud service credential. It was provisioned months ago, probably by copying it into an environment variable or a secrets manager. It has broad permissions — more than the agent needs for any single task, because scoping permissions precisely was too much friction at the time. It does not expire. Nobody has audited its usage in weeks.

This is the default state of credential management in AI systems today, and it is a security incident waiting to happen.

The Problem With Long-Lived API Keys

Traditional API key management was designed for a world where software was relatively static. A server application gets a database credential at deployment time and uses it for the lifetime of the process. The trust model is simple: the application is trusted, the credential grants access, and access is binary — you either have it or you do not.

AI agents break every assumption in this model.

Agents are dynamic. An agent’s behaviour is determined at runtime by the combination of its instructions, the user’s input, and the model’s interpretation. You cannot predict at deployment time what resources an agent will need to access or what operations it will perform. A coding agent might need to read a file, execute a shell command, call an API, and create a pull request — all within a single user interaction, with the specific sequence determined by an LLM.

Agents spawn sub-agents. Modern agentic architectures involve delegation. A planning agent dispatches tasks to specialised sub-agents, each of which may need its own credentials. If the parent passes its own credential to the child, you have credential sharing with no audit trail. If the child needs a credential of its own, you need a provisioning mechanism that operates at the speed of agent execution.

Agents are exposed to adversarial input. Every agent that processes user input or external data is subject to prompt injection. A compromised agent with a long-lived, broadly-scoped credential is not just a malfunctioning program — it is a credential theft vector. The blast radius of a successful injection is bounded by the permissions of the credential the agent holds.

Agents are hard to audit. When a traditional application makes an API call, the call is predictable and the audit trail is straightforward. When an LLM agent makes an API call, the decision was made by a neural network operating on natural language. Understanding why a particular call was made requires reconstructing the agent’s reasoning, not just inspecting the call log.

The Zero-Trust Response

Zero-trust architecture is built on a simple principle: never trust, always verify. Applied to AI credential management, it translates to four requirements.

Time-limited tokens. Every credential issued to a client or agent should expire on a timescale proportional to the work it needs to do. If it leaks after the task is done, it is already dead.

Scoped permissions. A token should grant the minimum permissions the task needs. An agent that generates completions should not also be able to fine-tune models, read billing data or delete resources. The scope is a ceiling, enforced before the request reaches the underlying API, regardless of what the real key could do.

Auditable usage. Every use should be attributable: which token, which operation, which outcome, and — for agent hierarchies — which parent authorised the token’s creation, so a call can be traced back through the delegation chain to the original request.

Instant revocation. If a client or agent misbehaves, its credential should be revocable immediately, without rotating the real key and redeploying everything that depends on it.

The common thread is indirection: the real key stays in one place, and everything else holds a derivative credential that is narrower, shorter-lived and individually accountable.

What perishable Implements

perishable is our exploration of the first of these requirements in the setting where the problem is most acute: a browser application that needs to call an LLM API. A key in client-side JavaScript is visible to anyone who opens developer tools. Not shipping it means building a backend, which for a static site, a demo or a documentation playground is a disproportionate amount of infrastructure.

perishable is a self-hosted Node proxy plus a browser SDK. The real key never leaves the server:

Browser  →  Perishable Proxy  →  OpenAI-compatible API
   ↑              ↓
   └── JWT + Fingerprint ──┘

Starting the proxy is one command, OPENAI_API_KEY=sk-... npx perishable-proxy, and the browser side looks like an ordinary client:

import { client } from 'perishable';

// Call once on page load: collects interaction entropy
client.PerishableOpenAI.initEntropyCollection();

const ai = new client.PerishableOpenAI({ proxyUrl: 'http://localhost:3000' });

const response = await ai.createChatCompletion({
  model: 'gpt-4',
  messages: [{ role: 'user', content: 'Hello!' }]
});

Underneath, it layers five defences:

1. Client fingerprinting derives an identifier from browser characteristics.
2. Entropy collection requires genuine mouse or keyboard activity before a session is issued, which makes trivial automation more expensive.
3. JWT sessions are short-lived and tied to the fingerprint, so a token lifted from one browser is not simply reusable from another. The SDK refreshes ahead of expiry.
4. Rate limiting is applied per client rather than globally, so one abusive client cannot exhaust the budget for everyone.
5. CORS protection restricts which origins may call the proxy.

The proxy forwards to any OpenAI-compatible endpoint — OpenAI by default, and Anthropic, OpenRouter or a local Ollama instance by setting a base URL. Rate limits and fingerprint rules are configured in code or a config file:

import { server } from 'perishable';

const proxy = new server.PerishableServer({
  openaiApiKey: process.env.OPENAI_API_KEY,
  port: 3000,
  rateLimitOptions: { points: 100, duration: 60, blockDuration: 60 },
  clientValidationOptions: {
    enableFingerprintValidation: true,
    maxSessionsPerFingerprint: 5,
    enableEntropyValidation: true
  }
});

proxy.start();

What perishable Does Not Do

It is worth being as clear about the gaps as about the features, because a security tool described more generously than it deserves is worse than no tool at all.

It is not bot-proof. Fingerprinting and entropy raise the cost of casual abuse. A determined attacker with a headless browser and patience will obtain sessions. What perishable prevents is the realistic failure: a key scraped from a public bundle and used at scale within hours.

It does not implement scopes. A session grants access to the proxied API; there is no per-endpoint or per-operation scope declaration that caps what a particular token can do.

It does not track delegation or provide a revocation API. There is no token lineage linking a sub-agent’s credential to its parent’s, and no operation to revoke every token issued to a given agent. Sessions end by expiring.

It is not an identity system. If you know who your users are, authenticate them properly and issue credentials against identity. Fingerprinting is what you reach for when you cannot — a public demo, a documentation site with a live playground.

So perishable covers one of the four requirements well for one setting: time-limited, client-bound credentials in front of a key that must not be exposed. The agent-hierarchy case — scopes, lineage, revocation — is a credential broker that does not exist in perishable today, and we would rather say so than imply otherwise.

Comparison With Traditional Approaches

The standard approach to API key management in AI systems is one of three patterns:

Environment variables. The key is set at startup and every process in the environment can read it. There is no scoping, no expiration and no per-request attribution.

Secrets managers. The key is stored in a service such as AWS Secrets Manager or HashiCorp Vault and retrieved on demand. This is better — the key is encrypted at rest and access is logged — but the retrieved key is still long-lived, broadly scoped and shared across requests. Vault and similar tools also solve the general credential problem properly when the calling code runs somewhere you control.

Key rotation. Rotating on a schedule limits the window of exposure if a key leaks, but does not address scoping, attribution or delegation, and rotation frequency is limited by the cost of updating every dependent.

The proxy-token model is orthogonal to all three. You still store the real key in a secrets manager and still rotate it. What changes is that the parties most likely to leak a credential — a browser, an agent processing untrusted input — never hold the real one.

Why This Matters More in an Agentic World

Agent autonomy means unpredictable access patterns. A traditional application calls the same endpoints in the same order every time. An agent’s access pattern is chosen by a language model at runtime. Scoped credentials bound the worst case.

Agent delegation means credential proliferation. When agents create sub-agents, credentials multiply. Without ephemeral, attributable tokens, either every sub-agent shares the parent’s credential or someone must provision credentials by hand at a speed no human can match.

Prompt injection makes credential theft a runtime risk. A leaked environment variable is a deployment failure. A prompt injection that exfiltrates a credential can happen on any interaction. Short-lived credentials limit the damage: a stolen token that expires soon is an incident with an end date.

Agentic systems are harder to reason about. When behaviour depends on a language model, code review alone cannot establish security properties, and defence in depth becomes the default. Ephemeral credentials do not prevent attacks; they bound their consequences.

Where This Leaves Us

perishable is narrow on purpose, and its narrow case is real: every public AI demo that ships a key in its bundle is a liability, and a proxy that keeps the key server-side while making abuse more expensive is a cheap fix. Its source is public; the repository does not yet carry a licence file, so we do not describe it as open source until one is added.

The broader pattern — scoped, attributable, revocable credentials for agents that delegate to agents — is the harder problem, and it is the one most teams deploying agents today have not solved. The requirements above are a specification for that broker. Until something implements them, the minimum is to keep real keys out of the places most likely to leak them, and to be honest about which of the four properties your setup actually provides.