Daniel wrote in with something that's been rattling around my head ever since I read it. The core image is this: your AI agent — the thing managing your calendar, your email, your code repos, your cloud infrastructure — it's been running for weeks, and it's accumulated OAuth refresh tokens and API keys and certificates for, let's say, sixty or seventy different services. All of that has to live somewhere between sessions. And the question is... where? And who can see it?
Right. And it's not one question, it's three, and they stack. First: is the thing we already have — macOS Keychain, Windows Credential Manager, 1Password — is that actually the right model for an agent, or are we jamming a square peg into a round hole? Second: what's already being built that's agent-specific? And third — this is the one that keeps me up — should the agent ever see the secret at all? Or should we be building a credential broker that injects auth without ever revealing the underlying token?
So today we're asking what the agent equivalent of the human password manager is. And whether that's even the right question.
Let's start with what we already have, because the OS keychain model is genuinely elegant for what it was designed to do. macOS Keychain stores secrets in an encrypted database — the encryption key is derived from your login password. You log in, the keychain unlocks, and every app that needs a password can request it through a system API. Windows Credential Manager does something similar with the Data Protection API. Linux has the Secret Service API over D-Bus, with things like GNOME Keyring sitting on top.
And the common thread in all of those is that there's a human at the keyboard who typed a password this morning.
That single moment — the human unlocking the vault at login — is load-bearing. Everything downstream assumes a user session with a conscious person who can approve or deny individual credential requests. Even third-party password managers like 1Password add a second factor on top of that, but the model is the same: a human unlocks the vault, and then applications can ask for secrets one at a time.
So let's walk through what breaks when you replace the human with an agent. First problem: the agent is headless. It's running on a server somewhere, or in a container that gets spun up at three in the morning. There's nobody to type a master password.
And you can't just hardcode the master password in an environment variable, because now that environment variable is the key to every credential the agent has. You've replaced sixty secrets with one secret, which is... better operational hygiene, I guess, but you haven't solved the fundamental problem. If the agent is compromised, the attacker gets the master password and then everything.
Second problem: concurrency. A human authenticates to one service at a time. You log into your email, then your calendar, then your cloud console. An agent might need to check your calendar, read an email thread, pull a file from cloud storage, and push a commit to GitHub all in the same workflow — six different services, six different OAuth tokens, all active simultaneously.
And OS keychains aren't really designed for that kind of concurrent access pattern. They serialize requests. A human clicking through a login flow doesn't notice a hundred-millisecond delay. An agent making thirty API calls in parallel absolutely does.
Third problem — and this is the one I think is actually the hardest — consent. A human can look at a dialog box that says "Slack wants to access your keychain" and make a judgment call. An agent can't. It'll use any credential it can reach, because its entire job is to accomplish the task you gave it. The concept of "should I use this credential for this action" doesn't exist in the agent's decision space unless you build it in explicitly.
Which nobody does, because the whole point of an agent is that it's autonomous. If it has to ask permission for every credential use, you've built a very slow RPA bot, not an agent.
Fourth: rotation. In a human keychain, credential rotation is manual. Your GitHub token expires, you get an email, you go generate a new one and paste it in. An agent with access to sixty services can't do that — it needs automated rotation, and it needs it across services that all have different rotation policies and different token lifetimes.
And this is where the infrastructure world has actually been ahead of the curve. HashiCorp Vault has been doing dynamic secrets for years. The idea is: instead of storing a long-lived API key, Vault generates a short-lived credential on demand, gives it a lease — say, twenty-four hours — and then revokes it automatically when the lease expires. The agent never stores a permanent secret; it just asks Vault for a new one when it needs it.
But Vault was designed for services, not agents. The trust model is different.
Right. Vault assumes a trusted workload identity — a Kubernetes service account, an EC2 instance role, something that says "this is the payments service and it's allowed to access the payments database." The identity is static and tightly scoped. An agent doesn't have a static identity in the same way. It might be doing calendar stuff in the morning and infrastructure provisioning in the afternoon, all under the same agent identity. And the agent is an autonomous decision-maker — it can be tricked, prompt-injected, or simply make a bad call. Vault's model doesn't account for the credential consumer itself being a potential threat.
So the OS keychain fails on headless operation, concurrency, consent, and rotation. And the infrastructure secrets model fails on the identity and trust assumptions. Which means we need something purpose-built.
And people are building it. Google announced something called Agent-to-Auth at Cloud Next earlier this year. The architecture is: the agent doesn't get a token at all. It sends a request to an auth layer that says "I need to list the user's emails." The auth layer checks policy — is this agent allowed to do that? Is the user's consent on file? — then fetches the actual OAuth token from a secure store, makes the Gmail API call, and returns only the result to the agent. The agent never sees the token.
So it's a broker. The credential lives entirely server-side.
Completely. And Microsoft's Copilot extensions use a similar delegated auth model. The agent gets a scoped token for a specific operation — "send one email" or "read one calendar event" — not a blanket "here's access to the entire Microsoft Graph API." The scope is baked into the token itself, and the token is short-lived.
That's a fundamentally different mental model. A human password manager is a vault you unlock and then rummage through. This is a butler you hand instructions to. "Send this letter." The butler has the key to the post box; you don't.
And the butler metaphor is actually useful here, because it surfaces the tradeoff immediately. A butler is a single point of failure. If the butler is slow, every errand is slow. If the butler is compromised, the attacker gets everything the butler had access to. If the butler goes down, you can't send any letters at all.
Versus the vault model, where if the agent is compromised, the attacker gets... everything in the vault. Which is also everything. So both architectures have a catastrophic failure mode. The difference is where the catastrophe happens and how fast you can recover.
The broker model gives you better containment options. If the broker is the only thing that ever touches raw credentials, you can harden that one component — put it in a hardware security module, give it its own isolated network segment, audit every request it processes. The agent can run in a much less trusted environment because it doesn't have anything worth stealing.
And revocation becomes a single action. You revoke the agent's access to the broker, and suddenly the agent can't do anything. You don't have to rotate sixty individual service credentials.
Which brings us to the isolation question Daniel raised. If one agent has access to dozens of services, what does the architecture need to provide? Three things, I think. First, compartmentalization. A compromise of the credential for service A should not cascade to service B. If the agent's Slack token leaks, that shouldn't give the attacker the AWS credentials.
In the keychain model, it does. The agent has all sixty tokens in one database, unlocked by one master secret. Compromise the agent's runtime, and you get everything.
Second, least-privilege per session. If the agent spawns a sub-agent to handle calendar operations, that sub-agent should get a scoped credential that can only access the calendar — not email, not cloud storage, not anything else. The OS keychain has no concept of delegation or sub-credentials. You either have access to the keychain entry or you don't.
And third, revocation at scale. If you detect that the agent has been compromised — maybe it started making weird API calls at three in the morning — you need to revoke everything instantly. Not rotate credentials one service at a time over the next hour while the attacker exfiltrates data.
The broker model handles all three of these naturally. The broker is the choke point. It can enforce per-request policy, it can issue scoped sub-tokens to sub-agents, and it can revoke an agent's access with a single API call or a literal panic button.
So the broker model seems strictly better for security. What's the argument against it?
Latency and coupling. Every single action the agent takes now has to go through the broker. If the agent wants to check your calendar, it sends a request to the broker, the broker authenticates, checks policy, fetches the token, makes the API call, and returns the result. That's a round trip that didn't exist before. If the broker adds two hundred milliseconds to every action, and the agent is doing hundreds of actions per session, that adds up.
And if the broker goes down, the agent is a brick. It can't do anything. You've traded a security risk for an availability risk.
There's also a policy complexity problem that I don't think gets enough attention. Who writes the policy that the broker enforces? If the agent is supposed to be autonomous — booking meetings, sending emails, managing infrastructure — who decides which actions are allowed and which aren't? The human can't pre-authorize every possible action; that defeats the purpose of having an agent.
You end up with a policy engine that's trying to predict whether an action is reasonable based on context. "The agent is trying to delete a production database at 4 a.m. on a Saturday — that's probably not legitimate." But now you've built a second AI to guard the first AI, and you've got to hope the guard AI is smarter than the attacker.
And we haven't even touched the agent identity problem. In a broker model, the agent needs its own identity that the broker can authenticate. This is fundamentally different from a human identity. The agent might have a cryptographic key pair generated at deployment time, or a workload identity issued by its cloud provider, or some kind of verifiable credential. The broker maps that agent identity to a set of authorized actions — "agent seven-one-three can read email and access calendar, but not touch billing."
Which means you need an identity system for agents that's as robust as the identity systems we've built for humans over the past thirty years. And we're basically starting from scratch.
Well, not quite from scratch. The infrastructure world has SPIFFE and OAuth and mutual TLS for service-to-service auth. But those all assume the service has a well-defined purpose. An agent doesn't. Its purpose is whatever the user asked it to do five minutes ago.
So let me try to synthesize where we are. The OS keychain model fails for agents because it assumes a human in the loop, serial access, manual rotation, and no delegation. The infrastructure secrets model — Vault and its ilk — gets closer, but it assumes a trusted workload with a static identity, not an autonomous decision-maker that might be compromised.
The emerging agent-specific systems — Google's Agent-to-Auth, Microsoft's delegated auth for Copilot — are converging on a broker architecture where the agent never sees the raw credential. The agent requests an action, the broker injects the auth and performs the action on the agent's behalf.
That architecture gives you compartmentalization, scoped sub-credentials, and instant revocation. But it introduces a single point of failure, adds latency to every action, and requires a policy engine that's smart enough to distinguish legitimate agent behavior from a compromise — which is an unsolved problem.
There's a middle ground that I think is worth mentioning. Instead of a broker that performs every action on the agent's behalf, you could have a broker that issues short-lived, narrowly-scoped tokens to the agent. The agent gets a token that's valid for fifteen minutes and can only access one specific API endpoint. The agent does see the token, but the token is so constrained that exfiltrating it doesn't gain the attacker much.
That's basically what OAuth was supposed to be, right? Scoped, short-lived access tokens. The problem is that in practice, everyone requests the broadest possible scope and tokens live for months because rotation is a hassle.
That's the human problem, not a technical one. An agent doesn't get annoyed by frequent re-authentication. It can handle token rotation programmatically. So you could actually enforce the OAuth model as it was originally designed — narrow scopes, short lifetimes, automated rotation — in a way that humans never would tolerate.
Which suggests that the real answer to Daniel's third question — should the agent ever see the secret — might be: it depends on the secret. For high-value credentials like cloud infrastructure keys, use a broker that never reveals the token. For lower-stakes things like a read-only calendar scope, issuing a short-lived token directly to the agent is probably fine.
The architecture needs to support both modes. A single agent might have broker-mediated access to your AWS account and direct token access to your read-only RSS feeds. The credential management system has to be able to make that distinction and enforce it.
Which brings us back to the policy engine problem. Somebody — or something — has to classify which credentials are high-value and which aren't, and write the rules that enforce that classification.
I think that's going to end up being a combination of the service provider and the user. The service provider says "access to delete production resources requires broker mediation." The user says "my calendar is medium sensitivity — scoped tokens are fine." And the credential system merges those policies and enforces them.
That's a lot of moving parts for something that, in the human world, is just a dialog box that says "allow this app to access your keychain?"
That's the thing. We're discovering that "just store the password somewhere" is a surprisingly deep problem when you remove the human from the loop. Every assumption embedded in thirty years of credential management — user presence, serial access, manual approval, human judgment — evaporates the moment the credential consumer is a piece of software making decisions at machine speed.
There's one more angle I want to poke at before we bring Hilbert in. We've been talking about agents as though they're a single process, but the agent architectures people are actually building are more like... an agent spawns sub-agents, which spawn tools, which call APIs. The credential problem recurses down the stack.
Each level of the stack should have less privilege than the level above it. The top-level agent might have broker-mediated access to everything. A sub-agent handling email gets scoped email tokens. A tool that formats text gets no credentials at all. That's the principle of least privilege applied recursively, and no existing credential system does it well.
Because existing systems assume a flat namespace. One user, one set of credentials. The idea that a credential might be delegated to a sub-process with additional restrictions layered on top — that's not in the OS keychain model at all.
Vault can do something like it with wrapped tokens — you can create a token that's itself a wrapper around a more restricted token, and the wrapper can only be unwrapped once by a specific consumer. But it's clunky, and it wasn't designed for the kind of deep delegation chains that agent architectures want.
We need a credential system that understands delegation natively. "I am agent A, and I am delegating calendar-read access to sub-agent B for the next ten minutes." And sub-agent B can't escalate that to calendar-write or email-read.
Which starts to look less like a password manager and more like a capability-based security system. Each credential is a capability — a token that says "bearer can perform action X on resource Y until time Z." And capabilities can be delegated and attenuated — you can take a capability and create a weaker version of it to hand to a sub-process.
Capability-based security has been an academic idea for decades. It's never really broken into the mainstream because it's hard to reason about and harder to implement. But agents might be the killer app that forces it into production.
Because the alternative — giving every sub-agent a copy of the master credential — is obviously insane once you say it out loud.
Thirty seconds.
Hilbert: YubiKey 5C NFC. Fifty-five dollars.
...Go on.
Hilbert: I spent three years as a sysadmin for a hedge fund in Greenwich. This would have been oh-four to oh-seven. They had trading bots — we called them the robots, nobody was saying "agent" back then — and each bot had its own hardware security module. Physical HSM, bolted to the rack, with a per-bot private key that never left the module. The bot would send a trade instruction to the HSM, the HSM would sign it with the bot's key, and the exchange would only accept signed instructions. The bot never saw its own signing key.
You were running a credential broker before anyone had the vocabulary for it.
Hilbert: We were running a mess, is what we were running. The HSMs talked to a Perl script that talked to a Java service that talked to the exchange gateway. The whole thing was held together with... I want to say hope, but really it was a lot of SSH tunnels and a monitoring script that paged me if anything stopped responding.
How many bots?
Hilbert: Twelve. Each one had exactly one job — one exchange, one instrument, one strategy. The credential scope was baked in at the hardware level. Bot number four could trade Eurodollar futures on the CME and nothing else. If someone compromised bot four, they could... trade Eurodollar futures. Badly, probably, but they couldn't touch the equity options bots or the FX desk.
That's the compartmentalization we were describing. One bot, one credential, one scope.
Hilbert: It worked because the bots were stupid. They weren't making decisions about what to trade — they were executing a strategy that a human had defined. The policy was in the strategy code, not in the credential system. Your AI agent is different. It's making decisions. The credential system has to be smarter because the thing it's guarding is smarter.
What happened when something went wrong?
Hilbert: We had a panic button. Big red physical button on the trading desk that severed every bot's connection to every exchange instantly. One Saturday, a new guy — intern, I think — was being shown around the office, and someone said "don't touch the red button," and he touched the red button.
During trading hours?
Hilbert: Tuesday, eleven in the morning. The firm lost about two million dollars in missed trades before we got everything reconnected. Took forty minutes to bring all twelve bots back online because each one had to re-establish its session with the exchange, and the exchanges had rate limits on session negotiation.
The panic button worked perfectly, and it still cost two million dollars.
Hilbert: That's the thing about revocation. Revoking is easy. Coming back from revocation is hard. If your agent credential broker has a panic button — and it should — you'd better have a plan for what happens after someone pushes it. Because the agent is going to come back online and discover it's been locked out of sixty services, and now it has to re-authenticate to all of them simultaneously while the user is wondering why their calendar isn't updating.
The blast radius of a false positive in an agent credential system is enormous.
Hilbert: The blast radius of a false negative — not revoking when you should — is worse. The hedge fund guys understood this. They accepted that occasionally they'd lose money to a false revocation because the alternative was losing everything to a compromised bot. But they were traders. They thought in expected value. Most people building agent systems aren't thinking that way yet.
Did the intern keep his job?
Hilbert: He did not. But my brother-in-law worked at a prop shop in Chicago that had a similar setup, and he always said the real problem wasn't the panic button — it was that nobody had ever practiced recovery. They'd tested the button, confirmed it killed all connections, and called it done. Never once ran a drill where they actually had to bring everything back online under time pressure.
That's a remarkably specific lesson to surface from a hedge fund in 2006.
Hilbert: My brother-in-law is not a reliable source on most things, but he's right about this one. Everyone designs for the revocation. Nobody designs for the recovery. And with agents, the recovery is the hard part. You've got an agent that's been running for three weeks, it's built up state, it's in the middle of seventeen workflows, and suddenly all its credentials are gone. How does it resume? What does it tell the user? Does it even know what it was doing?
Those are workflow continuity questions that the credential system itself can't answer. The agent runtime has to handle them.
Hilbert: Which means the credential system and the agent runtime can't be separate products from separate vendors. They have to understand each other. The broker needs to tell the agent "you've been revoked, here's why, here's what you had in flight, here's how to resume." And the agent needs to be designed to receive that message and act on it.
Nobody's building that today.
Hilbert: Nobody's building that today.
If you take one thing from this, it's that the question isn't really "keychain versus broker." The question is whether we design credential systems that understand what an agent is — an autonomous decision-maker that operates at machine speed, delegates to sub-processes, and needs to recover gracefully from revocation.
Right now, we're bolting agent auth onto systems designed for humans who type passwords and services that have one job. Neither model fits. The broker architecture is the right direction, but the hard part isn't the broker — it's the policy engine behind it, the delegation model, and the recovery path.
The open question I keep coming back to is whether we'll get a standard for this or whether every platform builds its own. Google's got Agent-to-Auth, Microsoft has delegated Copilot auth, Amazon will have something — and if they don't converge, an agent that works across clouds has to speak three different credential protocols.
Which is exactly where we were with identity before OAuth and OpenID Connect. Twenty years of fragmentation, and then eventually a standard. The question is whether the agent ecosystem can afford to wait that long.
Thanks to Hilbert Flumingtop for producing, and for the hedge fund war stories we didn't know we needed.
This has been My Weird Prompts. If you've got a weird prompt about agent security, identity, or the future of autonomous systems, email the show at show at my weird prompts dot com. We read everything that comes in.
We'll be back soon.
