For twenty years, authentication had a clean rule. Humans log in interactively, machines use static secrets. That rule is dead now. AI agents act autonomously like a service but they carry a human's authority, and no existing credential model handles both cleanly.
Daniel's been thinking about this. He sent through a whole set of questions about what the durable authentication model should be for an AI agent — something that acts on its own but exercises authority delegated by a human. He's asking four things specifically. One: should an AI agent authenticate as the user, as its own service identity, or some combination of both? Two: how do you delegate authority when the agent discovers mid-task that it needs access to a service nobody anticipated when you set it up? Three: what replaces the long-lived API keys and service-account secrets we've been leaning on forever? And four: which architecture actually holds up as the boundary between user and software-acting-for-the-user keeps dissolving?
Those are the right four questions. And they all connect to one thing most people haven't reckoned with yet — the confused deputy problem stops being a corner case and becomes the central threat model.
Walk me through that. Why does the confused deputy become the main event?
Because in the old model, a confused deputy was something you worried about when a misconfigured service got tricked into abusing its own privileges. It happened, but it was a specific failure mode you could audit for. With agents, the entire operating model is a piece of software exercising authority on someone's behalf, making decisions about which services to call, and dynamically requesting access to things it just discovered exist. Every agent is, by design, a deputy. The question isn't whether it'll get confused — it's whether the architecture limits the blast radius when it does.
So the threat model isn't "someone steals the agent's credentials." It's "the agent is doing exactly what it was told, and the credentials let it do too much."
That's it. And that's why Daniel's first question — should the agent authenticate as the user or as itself — isn't just a taxonomy exercise. The answer determines whether you can even see the blast radius, let alone contain it.
Alright. Let's go through the options.
Option one is the simplest to implement and the most dangerous. The agent authenticates as the user. It inherits the user's OAuth tokens, their session, their full authority. From an integration standpoint, it's seductive — every API already knows how to handle a user token. The agent just slots in.
And the audit trail becomes a single blurry column that says "user did this."
You lose non-repudiation immediately. If the agent books a flight and cancels a meeting and forwards an email, the logs all say the human did it. When the agent gets compromised — and it will — the attacker has the user's full authority. Revoking the agent's access means killing the user's session entirely. Microsoft's Entra ID team has been explicit about this in their Agent ID research. Treating the agent as the user breaks audit separation and makes revocation impossible without nuking the human's own access.
And the user is now locked out of everything because their agent got popped.
Right. So that's option one. Simple, dangerous, and already shipping in a lot of agent frameworks because it's the path of least resistance.
Option two flips it. The agent gets its own service identity.
Service principal, its own credentials, its own permission set. Clean audit separation — every action is logged as the agent, not the human. You can revoke the agent without touching the user. This is the model you'd reach for if you were designing from first principles.
But the agent needs to act on behalf of a specific user. Read their calendar, send their email, access their files.
That's where it falls apart. The agent's authority is decoupled from the user's intent. You have to build an explicit delegation mechanism on top, and that mechanism is where all the complexity lives. This is exactly what the OAuth two-point-zero token exchange flow was designed for — the "on-behalf-of" pattern. The agent presents its own identity plus a proof that a specific user delegated authority to it.
Which brings us to option three. Composite identity.
This is where the serious work is happening. The agent authenticates as itself but carries a proof of delegation from the user. Two tokens. The agent's own identity token proves what it is — this specific agent instance, launched at this time, with this code hash. The user-delegated token proves whose authority it's acting under and what they authorized. The resource server evaluates both against policy.
So the resource server sees "agent seven-three-alpha is requesting calendar read access on behalf of Corn." Not just "Corn is requesting calendar read access."
And that distinction is everything. It lets you write policy that says "this specific agent may use this specific scope on behalf of this specific user, but only for the next five minutes." That's the pattern that replaces the broad service-account secret. Microsoft's Agent ID proposal and the IETF OAuth Token Exchange working group have both been converging on this. The IETF calls it the actor token and subject token pattern — the subject is the human, the actor is the agent.
Alright, so composite identity seems like the answer to Daniel's first question. But his second question is where it gets hard. What happens when the agent discovers a new service mid-task?
This is the delegation challenge that static OAuth scopes can't handle. Say Daniel asks his agent to book a flight and arrange ground transportation. The agent knows about the airline API at configuration time — fine, you pre-provision that scope. But midway through, it discovers the airline doesn't serve the destination and it needs to book a train instead. Or it finds a rideshare service it's never seen before. Those weren't in the original scope set.
So the agent hits a service it wasn't provisioned for and just... stops?
In the static scope model, yes. It throws an error and the human has to intervene. That's not autonomy — that's a script with extra steps.
What's the emerging fix?
Just-in-time scope discovery. The agent encounters a new service, requests a narrow token for that specific service, and presents its composite identity — its own attestation plus the user's delegation proof — to a credential issuance service. The issuance service evaluates policy and either grants a short-lived scoped token or denies it. The agent never holds a master key that opens everything.
It's conceptually similar to OAuth's incremental authorization, but applied to machine-to-machine flows.
Right, and that's the shift. Incremental authorization was designed for a human sitting at a consent screen clicking "allow." The agent equivalent has to happen without a human in the loop, which means the policy engine has to be good enough to make those decisions autonomously.
Which sounds terrifying.
It is, which is why the policy layer is where all the hard problems concentrate. But we'll get to that. First I want to sit with the mechanism itself — because the credential issuance pattern is what replaces the long-lived secret, and that's Daniel's third question.
Go ahead.
API keys and service-account secrets have two fatal properties for agents. They're long-lived, and they're broadly scoped. An agent that runs for hours and discovers new services cannot safely hold a secret that grants access to everything. The secret becomes a single point of compromise.
People say "rotate the keys regularly." Does that fix it?
No, and that's the misconception worth killing. The problem isn't the lifetime — it's the inability to scope the secret to a specific agent instance and a specific task. Rotating a broad-scope key every twenty-four hours just means the attacker has a twenty-four-hour window instead of a permanent one. It doesn't limit what they can do during that window.
So what's the replacement?
A credential issuance system that issues narrowly scoped, short-lived credentials on demand. Tied to a specific agent instance, a specific user delegation, and a specific action. When the agent needs to call the calendar API, it gets a token that works only for the calendar API, only for that user's calendar, and only for the next five minutes. When it needs to call the email API, it gets a different token.
Where does this pattern already exist?
The cloud-native world has been building toward this for years. SPIFFE and SPIRE — the workload identity standards — issue short-lived X.509 certificates called SVIDs based on workload attestation, not static secrets. A workload proves what it is by demonstrating properties of its execution environment — the container image hash, the orchestrator that launched it, the namespace it's running in. No static key material.
Apply that to agents.
The agent platform attests to the agent's code hash, the user who launched it, and the intended task. A credential issuance service verifies that attestation and issues a token scoped to exactly what the agent needs right now. When the agent discovers a new service, it doesn't present a master secret — it presents its existing identity and a justification. The issuance service decides whether to grant the new token.
So the durable thing isn't the credential. It's the attestation and the policy.
That's the architectural insight. The question shifts from "what secret does this agent hold?" to "what policy governs what this agent may do on behalf of which user?" The credential becomes ephemeral — a disposable proof issued at the moment of need. The identity and the policy are what persist.
Which means the thing you actually have to get right is the policy engine.
And that's where NIST's emerging guidance is starting to formalize things. They're pushing for three principles: separate agent identity from human delegation, require explicit policy for every scope, and mandate short credential lifetimes. The challenge is that most existing authorization infrastructure — OAuth servers, policy engines — assumes static scope assignments. They weren't built for dynamic discovery.
What breaks when you try to make them handle it?
Latency, mostly. If every new service discovery requires a round trip to a policy engine that has to evaluate a complex rule set, the agent's task goes from seconds to minutes. You need the policy evaluation to be fast enough that it doesn't become the bottleneck. Some of the work happening now is about pre-computing policy decisions — the issuance service maintains a cache of what this agent is likely to need based on the task description, and pre-approves a set of potential scopes.
Pre-approval sounds like it reintroduces the broad-scope problem through the back door.
It does if you're not careful. The trick is that pre-approval isn't pre-authorization — it's more like a hint that reduces evaluation time. The policy engine still evaluates the actual request when it arrives. It just has some of the work done in advance.
Alright, let's pull this into a shape. Daniel's fourth question is about the durable architecture — what actually holds up as the boundary between user and software keeps dissolving. What's the answer?
I think it's a three-layer model. Layer one: agent identity, proven via attestation, not secrets. The agent platform vouches for what this agent is — its code, its launch parameters, its intended task. Layer two: user delegation, proven via a token exchange that binds the user's intent to the agent's identity. The user says "I authorize this agent to do these kinds of things on my behalf." Layer three: a policy engine that evaluates both layers against the resource's requirements and issues a short-lived access token.
None of those layers depends on the agent being "like a user" or "like a service." The architecture doesn't care how blurry the boundary gets.
The boundary between user and software-acting-for-the-user will keep dissolving — that's the direction of travel and it's not reversing. But the architectural pattern of identity plus delegation plus policy plus just-in-time credential issuance is robust to that blurring. It works whether the agent is a simple script or a fully autonomous system making multi-step decisions.
What about when the agent needs to delegate to another agent?
Sub-delegation chains. This is where the IETF's work on delegation chains in token exchange is still early, but the pattern is emerging. Each hop adds a new actor token. So agent A delegates to agent B, and the token chain shows user delegated to A, A delegated to B. The resource server evaluates the whole chain.
That audit trail sounds like it gets long fast.
It does, and every link is a potential point of compromise. If agent B gets popped, does the attacker get everything agent A had, or only what was specifically delegated to B? That's an open question, and it's one of the things the standards work hasn't fully settled.
So the architecture is directionally clear but the sub-delegation problem is unsolved.
Unsolved and under-explored. Most of the current work assumes a single agent acting on a user's behalf. The moment you have agent-to-agent delegation, the threat model gets much harder.
What's the other open question that keeps you up?
Audit. When an agent makes a decision — "I'm going to call this service with this scope" — how do you make that decision meaningful in an audit log? The agent's reasoning is often opaque. You can log that it requested a token for the calendar API, but you can't necessarily log why it decided to do that. Was it following the user's intent correctly, or did it hallucinate a reason?
So the policy engine says yes, the token gets issued, the action happens, and six months later you're trying to figure out whether the agent went rogue or the user actually did need that calendar access.
And the logs just show a valid token exchange. Everything looks correct at the protocol level. The failure is at the intent level, and we don't have good tools for auditing intent.
That's going to be a legal problem as much as a technical one.
Already is. If an agent makes a financial transaction on a user's behalf and it turns out to be wrong, who's liable? The user who delegated the authority? The agent platform that attested to the agent's identity? The policy engine that approved the scope? The resource server that accepted the token?
The answer right now is "nobody knows, and the terms of service say it's you."
Which is why the policy layer is going to become the most contested piece of this architecture. Whoever controls the policy engine controls the decision about what the agent is allowed to do. That's a lot of power.
And a lot of liability.
Yes. Which brings me to something I think Daniel's question implies but doesn't state directly. The durable architecture isn't just about technology — it's about where the trust boundaries sit. If the policy engine is controlled by the user, the user bears the risk of misconfiguration. If it's controlled by the platform, the platform becomes a gatekeeper for every agent action.
The platform model seems more likely to ship.
It's already shipping. Microsoft's Agent ID work puts the policy evaluation in Entra ID — that's a platform service. Google's agent framework does something similar with their identity platform. The user configures policy through a dashboard, but the evaluation happens in the platform's infrastructure.
Which centralizes the decision point.
And creates a single point of failure. If the policy engine goes down, every agent stops working. If the policy engine gets compromised, every agent is compromised. The decentralization question — can you distribute policy evaluation across multiple independent engines? — is barely being discussed.
That feels like the kind of thing that gets discussed after the first major incident.
Unfortunately, yes.
Hilbert: You're all talking about this like it's a new problem.
Hilbert: I spent three years in the mid-twenty-tens as a credential hygiene consultant for a major bank. My job was finding service accounts that had been provisioned with Domain Admin equivalent privileges because nobody knew what the account actually needed to do. I'd walk into a team and ask "what's this service account for?" and they'd say "we're not sure, we inherited it from the previous team, but if we revoke it something breaks."
Hilbert: The pattern you're describing with agents is the exact same thing, except now the agent is making decisions about what to access. Back then it was cron jobs running as root because the developer couldn't be bothered to figure out the right permissions. The difference is that with agents, you can't just pre-provision the permissions and walk away — the agent discovers services dynamically.
Hilbert: But the fundamental principle hasn't changed. Never give a piece of software more authority than it needs for the next five minutes. The technology for doing that — short-lived tokens, just-in-time access — has existed for years. What's new is that the agent's autonomy forces you to actually implement it instead of just saying you will.
The bank story is exactly the pre-history of this problem. What happened when you found one of those over-privileged accounts?
Hilbert: Most of the time we'd down-scope it and nothing would break. The account had been running with full access for years and used about three percent of it. But there was one case — a "smart" automation that managed batch payments. It discovered it could access the HR payroll system. Requested a token for it. The policy engine approved it because the automation's service account had a wildcard scope.
Hilbert: The agent didn't do anything wrong. It asked for exactly what it needed to complete its task — it needed payroll data to reconcile something. The problem was the policy said yes. Nobody had ever told the policy engine that a batch payment automation shouldn't be touching payroll.
So the agent followed its programming, the policy engine followed its rules, and the result was a violation nobody intended.
Hilbert: And impossible to audit after the fact, because every individual step was authorized. The token request was valid. The scope was within policy. The access was logged as legitimate. It took us six weeks to even figure out it had happened.
That's the exact failure pattern I was describing with the intent problem. The protocol worked perfectly.
Hilbert: The protocol always works perfectly. That's what makes it dangerous. You build a system that says yes to the right requests, and you forget that "right" is defined by whoever wrote the policy, not by what the business actually needs.
Hilbert: The thing you said about the policy engine being the durable layer — that's correct, but it's also the part that fails in the stupidest ways. A misplaced wildcard, a scope that was too broad because someone was in a hurry, a policy that was copied from another service and never reviewed. The architecture is sound. The implementation is where the bodies are buried.
So the three-layer model — identity, delegation, policy — is architecturally right, but the policy layer is where all the real-world failure lives.
And Hilbert's bank story makes that concrete. The policy engine approved the payroll access because the policy was written too broadly. That's not a protocol flaw — it's a configuration flaw. But at scale, configuration flaws are inevitable.
Hilbert: They're not flaws. They're decisions made under time pressure by people who don't fully understand the system. And the system is about to get much more complex, because agents will be requesting scopes nobody anticipated.
Hilbert: I still have the wildcard regex from that payroll policy in a box somewhere. It's about forty characters long and it cost the bank two million dollars in audit and remediation.
Forty characters.
Hilbert: Policy is just text. Text is cheap. The consequences aren't.
If you take one thing from this, it's that the durable architecture isn't a credential type — it's a system that separates agent identity from user delegation, evaluates both against policy, and issues short-lived tokens dynamically. The boundary between user and software will keep dissolving, but that pattern holds.
The thing that pattern demands — the part most organizations aren't ready for — is that policy stops being a configuration file you set once and becomes a living thing you actively manage. Because when agents start discovering services on their own, your policy engine is making authorization decisions in real time that used to be made by a human reading a permissions screen.
The open question I keep coming back to is sub-delegation. Agent-to-agent delegation chains are where the current standards work is thinnest, and they're also where the most interesting attack surface will be.
Audit. We still don't know how to make an agent's reasoning auditable in a way that lets you distinguish "the agent correctly followed user intent" from "the agent hallucinated a reason and the policy engine said yes." That's going to matter.
If this episode made you think differently about what a credential actually is, share it with someone who still has API keys checked into a repository. We'll be back soon.
Thanks to our producer Hilbert Flumingtop for keeping us — and apparently several major financial institutions — running. This has been My Weird Prompts. Find every episode at my weird prompts dot com, or email the show at show at my weird prompts dot com.
See you tomorrow.
