Agents act under delegated, scoped, expiring authority — never a service account
Do not give an agent a long-lived service account. Every tool call runs under authority delegated from a named person, scoped to the task, and expiring with it.
Tier is not strength
Tier says how much we know. Strength says how hard we are telling you to act. Scored independently.
Machine-readable target
{
"taskType": "agent-tool-call",
"configKey": "auth.agent.delegation_mode"
}Nothing consumes it yet. Day two: findings ship as defaults into the gateway, routing config and skill library.
Body
x-auth-broker-poc built a broker that mints short-lived, task-scoped credentials for agent tool calls from a human's session, and ran it in front of three internal tools for six weeks. The comparison was the previous arrangement: a service account with standing access. The broker added 40 ms per call and removed an entire class of finding from the red team's report (c-auth-broker-1).
The reason it is a 'do not': the service-account pattern fails in a way that is invisible until it is public. In the red-team exercise that preceded the POC, a prompt-injected agent with a service account exfiltrated a customer record through a tool it had no task-level reason to call. The same attack under the broker failed at the scope check (c-auth-broker-2). g-auth-broker-oauth-only records the intermediate idea — plain OAuth scopes — which was not granular enough: scopes describe what an application may do, not what this task may do.
Delegation has a second effect that clients care about more than the security team does: attribution. Every action an agent takes is traceable to the person who delegated it, which is what a conduct-risk review actually asks for (c-auth-broker-4). A service account produces a log full of actions by 'svc-agent-prod'.
Where it is hard: batch and scheduled agents with no human in the session. The POC's answer is a named owner who delegates with a longer expiry and a narrower scope, and a broker that refuses to mint anything without one. That is a policy decision, and it is the right one.
What it rests on
OAuth scopes cannot express task-bounded delegation: a scope names a resource class, not a principal–agent–task triple, so any scope broad enough for the task is broad enough for misuse.
A policy engine at the tool-call boundary adds under 15 ms p50; the cost of the pattern is in policy authoring, not latency.
Existing service-account patterns with tighter IAM roles are sufficient for agent delegation in regulated environments.
Field
Auth BrokerExperiment · running
Delegated-authority broker for agent tool callsGraveyard · abandoned
Plain OAuth scopes are enough for agent delegation “Never got a tenant to fail in.”