Our Agents Don't Have Keys Anymore

Every night, while nobody watches, a fleet of AI agents does real work inside T2D3 OS. One panel reviews the day's customer feedback and scores it. Another writes regression tests for whatever broke. One builds customer websites. One drafts a weekly post. They run unattended, on our own machines, on a schedule.

Until this weekend, every one of those agents carried a copy of the same key — a long-lived API credential stored as a secret, pasted once and trusted forever. This is how almost everyone runs automation, and for years it was fine, because automation used to be dumb. A deploy script doesn't read your customers' messages.

Our agents do. And that changes the math completely.

The problem: a key is a thing you can steal

A stored credential has three properties that should worry anyone running autonomous AI:

It's copyable. A key is just text. Anything that can read it can exfiltrate it, and a copy is indistinguishable from the original.

It outlives the leak. A long-lived key stolen today works next month. You won't know it's gone until the invoice arrives — or worse.

It doesn't say who's asking. Every agent holding the same key looks identical. When something misbehaves, the audit log shows one anonymous credential doing everything.

Now add the part that's specific to AI agents: they read untrusted text as part of their job. Our review panel reads whatever end users typed into a feedback box. Security people call the resulting failure mode the lethal trifecta — an agent that (1) reads attacker-controlled content, (2) holds real credentials, and (3) can reach the network. A sufficiently clever piece of feedback could, in principle, talk the agent into using ingredient 2 over ingredient 3. We had already de-fanged our agents' database access for exactly this reason. The AI key was the last long-lived secret in the room.

The fix: identity instead of secrets

The pattern is called workload identity federation, and the idea is older than AI: stop handing out copies of the office key; put a bouncer at the door who checks ID.

Concretely, when one of our agent jobs starts, it no longer reaches for a stored key. Instead:

1. The CI platform hands the job a signed, short-lived statement of identity — cryptographic proof that says "this is the feedback-review workflow, running on this exact repository and branch, right now." Nobody typed this credential anywhere; it's minted fresh for each run and expires in five minutes.
2. The job presents that proof to Anthropic, which verifies the signature and checks it against a rule we wrote once: only this repository, only this branch, only this audience.
3. If — and only if — it matches, the job receives a working credential that dies about ten minutes later.

There is nothing to steal at rest. There is nothing to rotate. A leaked credential is worthless within minutes. And every API call is now attributable to a specific workflow instead of one shared identity.

The part I find most satisfying is the kill switch. Turning off every agent's API access used to mean hunting down a secret and hoping no copy survived. Now it's archiving one rule in a console. Identity is revocable in a way secrets never are — you can't un-copy text, but you can absolutely stop believing an ID.

What we learned the hard way

Migrations like this are supposed to be an afternoon. Ours took a day longer, and the reason is worth sharing because nobody had written it down: the token exchange treats each identity proof as single-use. Present the same proof twice and the second attempt is refused — a replay defense, and a good one, but an undocumented one. Our setup step was validating the identity proof once (burning it), and then the agent tried to use the same proof and got an opaque "authentication failed" with no hint why.

Finding that took nine controlled experiments: same request from two different clients, byte-for-byte capture and replay through a local proxy, a probe that exchanged one proof twice on purpose and watched the second one bounce. We filed the finding upstream so the docs can say what we had to discover.

Here's the detail I keep coming back to: most of that forensic work was done by an AI agent — designing the experiments, reading the evidence, being wrong twice, and narrowing to the truth — with a human steering the two decisions that mattered and clicking the four buttons only a human could click. The debugging of the agent infrastructure was itself agent work. That's not a stunt; it's just what leader-leader looks like on an ordinary Saturday.

Autonomy you can sell is autonomy with a designed blast radius

The honest version of this post admits one thing: a single evaluation tool in our pipeline still uses an old-style key, because it doesn't speak the new protocol yet. We shrank that key's blast radius to one narrow job and moved on. Purity is not the goal. Designed blast radius is the goal.

That's the thought I'd leave you with, because it applies far beyond CI pipelines. Everyone selling AI agents is selling autonomy, and autonomy is only trustworthy when someone has answered, in advance and in writing: what exactly can this agent reach, for how long, as whom, and where is the off switch? Inside T2D3 OS we gate agent autonomy on the human lock — judgment captured once, production work flowing from it. This weekend we applied the same posture to the agents' own credentials: no standing power, only identity, checked at the door, expiring in minutes.

Give your agents work. Give them initiative. Don't give them keys.