You paste an API key into your agent. One line in a .env file. It works right away.
But that key is yours. Your access, your reach, your name on every call.
You just handed your identity to a piece of software that writes its own commands.
An agent is not you. It is a new actor on your system. It needs its own.
TL;DR: a static API key in an agent is your identity, on loan. Broad, no end date, shared, impossible to trace. An AI agent is a non-human identity, an actor in its own right. Give it its own: a short-lived token, scoped to its need, revocable, and traceable in the logs. The industry has a name for the target, workload identity, like SPIFFE. Not a shared secret sitting in a
.env.
This article is for developers and DevSecOps folks who put an AI agent in production, with access to real systems. Not in a demo.
The setup
An AI agent is a language model that calls tools and acts for you. I build one in Go, in a personal project.
The stack is standard. Go for the code. Postgres for the data. A Kubernetes cluster to host it. And the Anthropic API for the model.
For its secrets, the agent reads no hand-typed key. It carries a dedicated machine identity. That identity is scoped to one project, one environment, one path. I self-host Infisical for this. Infisical is a secret manager: a vault that stores and hands out keys.
I come from security, and I am a bit paranoid. Certified pentester, former Top 1% on TryHackMe. Handing my identity to an agent was a no.
A static API key is your identity, on loan
Look at what a static API key does. It proves who you are, once and for all. And often, the same key is used everywhere.
# .env: the bad idea
ANTHROPIC_API_KEY=sk-ant-...
DATABASE_URL=postgres://app:password@db/prod
STRIPE_KEY=sk_live_...
A key like that has four flaws. It is broad: it opens everything your account can do. It is eternal: no end date. It is shared: the same secret serves ten places. And it is mute: a log says "the key acted", never "the agent acted".
The problem is exploding in 2026. Secrets tied to AI are the fastest-growing leak category. GitGuardian counted 1.27 million of them in 2025 alone, up 81% from 2024. Worse: 64% of the valid secrets leaked in 2022 were still not revoked by early 2026.
Why does AI make it worse? Because it multiplies the actors. More agents, more services, more tokens lying around. Every key placed by hand is a leak waiting to happen.
Your agent is a non-human identity, treat it as one
In security, we split two worlds. Human identities: you, your users. And non-human identities: services, scripts, bots.
A non-human identity, or NHI, is anything that authenticates without being a person. An AI agent is one of them. It is a full actor, like a service account.
And those actors are already the majority. In a modern cloud, machines outnumber humans by dozens to one. The AI agent is just the newest arrival. The fastest, and the most unpredictable.
Be careful not to mix up two identities. There is the user the agent acts for. And there is the agent itself. They are two different things. The agent needs its own identity, separate from yours and from the user's.
In my services, that means two paths. When the agent acts for a user, I propagate that user's token, end to end. When it is a system task, with no one behind it, a service-to-service token takes over. Never both on the same call. The agent never invents an identity. It carries the user's, or its own.
Give it a short-lived token, never an eternal secret
The first rule is simple. Replace the eternal secret with a short-lived token.
We call it a just-in-time token, or JIT. The idea: the agent does not keep a key forever. It proves who it is, gets a token that lives for a few minutes, then that token dies.
The payoff shows up on the day of a leak. A stolen static secret works until you notice. Often, months later. A short-lived token is already dead when the thief arrives.
In my project, the agent knows no production key. It carries a machine identity. With it, an operator fetches its secrets and renews them on its own, continuously.
# The agent's machine identity, scoped to its perimeter
projectSlug: mimmo
envSlug: prod
secretsPath: /backend/mimmo-ai # nothing else
resyncInterval: 60 # renewed continuously
Same logic on the tooling side. For my automations, I prefer an app that mints a token on the fly over a personal token left lying around. The app proves its identity, gets a token that lives for an hour, acts, then the token expires. Nothing permanent to store, nothing to leak.
Two reflexes come with it. One: rotate the credentials often. Two: keep a red button. The day an agent goes rogue, you must be able to kill its identity in one command, without breaking the other nine.
Scope the identity to what the agent needs
A short-lived token is good. A short-lived and narrow token is better.
The principle is least privilege: grant only the rights that are useful, nothing more. Applied to identity, it gives a clear rule. One identity per agent. Not a single key shared by your whole fleet.
Why? An injection is a booby-trapped text that steers the agent off task. If it succeeds, the attacker inherits the current agent's rights. With a narrow identity, the damage stops there. With the master key, everything falls.
I saw the other approach up close, on a large-scale identity platform. Rights were not simple fixed roles. They were decided by attributes, on every request. This is called ABAC. Who are you, in what context, for which resource: the answer is computed on demand.
An agent deserves the same treatment. Its identity does not just say "this is an agent". It carries attributes: which agent, which environment, which perimeter. And access is decided from there.
Make every action attributable to the agent
A proper identity comes with a gift: traceability.
With a shared key, your log says "the service account deleted the record". Thanks, but who? Which agent, which session, on whose orders?
With one identity per agent, the answer is in the log line. You know which actor acted, when, and for whom. This is non-repudiation: no one can deny what they did.
This is not my idea. NIST is pushing a framework for agent identity. It fits in four words: identify the agent, authorize it, audit it, and tie every action to the human who allowed it.
In practice, every call from my agent goes to a structured log: which identity, which tool, which decision. The day of an incident, I answer one question. What did this agent do, exactly?
The target: a workload identity, like SPIFFE
Where is all this going? Toward a cryptographic identity for each workload.
The rising standard is SPIFFE, with its implementation SPIRE. The idea is elegant. Each service gets a verifiable identity, proven by cryptography, and short-lived. No more shared secret to copy from one place to another.
# A workload identity, not a shared key
spiffe://mimmo.app/agent/legal-advisor
# → a short-lived identifier, self-renewing, verifiable
And for AI agents? The shift is under way, at a high level. NIST launched an initiative dedicated to agents in February 2026. Its text on agent identity cites OAuth, OpenID Connect, and SPIFFE. A draft at the IETF describes an identity model for agents, AIMS, built on those same standards. And OWASP ranks excessive agency among the top risks for agentic applications.
Be honest about maturity. SPIFFE in production for agents is young. I watch this direction closely, without claiming I have deployed it everywhere. But the principle already applies. Short, narrow, revocable, traced identity. You do not need a final standard to stop pasting your key into a .env.
The checklist before granting access
Before you wire your AI agent to real systems, run its identity through this list.
- [ ] The agent has its own identity, separate from yours and from the user's
- [ ] No static key in a
.envor in the code - [ ] A short-lived token instead of the eternal secret, self-renewing
- [ ] One identity per agent, never a shared master key
- [ ] The identity is scoped: one project, one environment, one perimeter
- [ ] Access is decided by attributes, not by a fixed role (ABAC)
- [ ] A red button: you can revoke an identity in one command
- [ ] Regular rotation of credentials
- [ ] Every action is logged with the agent's identity, for non-repudiation
- [ ] Secrets live in a dedicated manager, scanned at every commit
- [ ] The target: a verifiable workload identity, like SPIFFE
What to remember
An API key answers "what access". An identity answers "who acts". Your agent needs the second one.
Do not lend it your identity. Give it its own: short, narrow, revocable, traced. That is the difference between an actor you control and a secret you pray never leaks.
The standards are coming. Machine identities are exploding. Developers who can give an agent a proper identity, and not just a key, will stay rare for a while.
Are you putting an AI agent into production? Do you want a second look at how it authenticates, before a key leaks? That is exactly what I do. Get in touch.
Sources: GitGuardian, State of Secrets Sprawl 2026 · NIST AI Agent Standards Initiative · NCCoE, Software & AI Agent Identity and Authorization · IETF draft, AI Agent Authentication (AIMS) · SPIFFE · OWASP Top 10 for Agentic Applications.
Top comments (1)
The SPIFFE direction and the per-agent identity checklist are both spot on. One gap I keep seeing in practice even after teams adopt a vault: the injection path matters as much as the storage. When a sidecar resolves secrets and dumps them as env vars at startup, the agent ends up holding the same broad access for its whole lifetime, just through one more layer of indirection. The real shift is scoping the credential to the individual tool call, not the container. The AIMS draft's token exchange pattern describes the target architecture, but the runtime mechanics to actually make that work per-tool-call are still getting worked out. We hit the same gap at CAI Labs and ended up building scoped per-call credential injection instead of boot-time secret resolve.