A while ago I built a small lab to learn about AI agent identity. In it, two AI agents each got their own ID badge from Okta, federated into Google Cloud with no static keys, and were held to least privilege by IAM — not by the agent "being nice". (That was the first article.)
But that lab had one big simplification: each agent acted only as itself. Real agents don't. They do work for a specific person. If an agent issues a refund, whose identity is on the audit log — the agent's, or the customer's? And can it touch only that customer's data, or everyone's?
Each agent already has its own identity — now that identity can carry a second fact: who it is acting for.
The setting
To keep it concrete I use a fictional shop, SkynarcWind Outfitters. The cast:
- Maya — a shopper.
order-agent— handles orders and refunds (read + write).cs-agent— customer service (read-mostly).
The goal: order-agent should be able to act on behalf of Maya — and reach only Maya's files, never another customer's.
An honest detour: Okta said "not for agents"
The standard way to do "on behalf of" is OAuth token exchange. I tried to switch it on in Okta and got a clear warning: "Token Exchange is not suited for AI Agent flows." Okta now sells a dedicated product for this (Okta for AI Agents / Cross App Access) — but it is a paid feature, and it is built for agents connecting to other apps, not my case of an agent reaching into cloud storage. On the free tier, Okta would not mint the "on behalf of" token for me.
So I built the one missing step myself — a tiny broker. This is the honest heart of the article.
The small broker (Okta is not replaced)
Okta still does its job: it logs Maya in, and it still issues the agents' identities. The broker only reads those Okta-issued tokens and enforces one rule. Here is the whole flow:
- Maya logs in at Okta → she gets a token.
- order-agent sends the broker two tokens: its own, and Maya's.
- The broker verifies both against Okta's public keys, checks a small "may act" list (is this agent allowed to act for this customer?), and mints a Google Cloud token scoped to only Maya's folder.
- order-agent uses that token: it can read Maya's file, and is denied any other customer's.
Two things I care about here:
- Still no static keys. The broker gets its own Google Cloud identity the same keyless way the agents do (Okta → Workload Identity Federation → a service account).
- The boundary is structural, not behavioural. Customer data lives in its own bucket that only the broker can reach. The agents have no access to it at all. So the only door to customer data is through the broker and its may act check — the agent literally cannot reach it another way.
Getting Maya a real login token on a free Okta org was, honestly, the fiddliest part: the silent headless login isn't supported on the modern engine, the app type had to change, the sign-on policy demanded MFA, and the authorization-server policy had to allow it. Undramatic plumbing — I mention it because it was most of the work.
The model does not decide who Maya is or what she owns. Okta says who everyone is; Google Cloud enforces what they can touch; the broker just carries "acting for Maya" between them.
The test
One command runs the whole thing: order-agent acting for Maya, then the same agent reaching for a different customer, then a different agent trying to act for Maya. The result:
====================================================================================
Agent Identity Lab — P2a delegation (order-agent acts on behalf of a customer)
====================================================================================
SCENARIO EXPECT RESULT
------------------------------------------------------------------------------------
OK order-agent for Maya reads maya/order-4471.txt allowed allowed
chain: agent=order-agent [email protected]
OK order-agent for Maya reads bob/order-5502.txt denied denied
chain: agent=order-agent [email protected]
OK cs-agent for Maya (confused-deputy gate) refused refused
====================================================================================
OK: delegation scoped correctly and the confused deputy was refused.Reading the three rows:
- Maya's file → allowed. order-agent, acting for Maya, reads Maya's order.
- Bob's file → denied. The same agent in the same run cannot read another customer — the token it was given only reaches Maya's folder.
- cs-agent for Maya → refused. This is the classic confused-deputy attack: one agent trying to get another to act for it. The broker's may act check says no.
And every action carries the chain: agent = order-agent, on behalf of = Maya. The audit log finally answers the question that matters — who did this, and on whose behalf?
maya/ and bob/ folders. Delegation scopes an agent to exactly one of these.
sa-delegation-broker (Storage Object Admin). The agents have no binding here at all; the broker is the only way in.
delegation-broker, the storefront login app that mints Maya's token, and the agents (plus sentinel, from the next article).
okta-pool Workload Identity pool — the badges become cloud access with no static keys.What I learned
- Delegation is a chain of custody. "Who authorized this?" deserves a real, logged answer — not a shrug.
- The confused deputy is real. Without a may act check, one agent can quietly borrow another's power. The defense is a rule, not good manners.
- The managed products exist now (Okta's Cross App Access, and others). I built the mechanism myself to understand it — a smaller, honest promise, and a pointer to where the production path would go.
- Structural beats behavioural. The agents can't reach customer data at all; a scoped, checked delegation is the only door.
And here's the thread to the next step: now every action carries "acting for Maya". That attribution is exactly what makes the next phase possible — if every action is attributable, I can finally watch for the one that shouldn't have happened, and shut it down. That's the next article: detect & respond.
This is still a private learning lab, not a product. If you work on non-human identity, agent security, or delegation, I'd genuinely like your critique — including the sharp kind.
—A Skynarc learning project on non-human identity.