Learn
How agents borrow your identity
A shared agent should not hand an intern the CFO's access. Getting that right takes one agent, not one per person.
The two models
Two ways an agent can act
An agent either acts as itself, or it acts for a person. That one choice decides whether the tools and models it can reach depend on who is using it, or are the same no matter who asks.
Standing identity: the agent acts as itself
A reconciler runs at 2am. Nobody asked it to and nobody is waiting on it, so the access it needs belongs to the job rather than to any person.
That leaves one thing to check: what this agent is allowed to do. That is standing identity.
Most automation wants exactly this. Handing a nightly job somebody's permissions would only widen what it can reach.
Personal is about memory, not permission
Dana's assistant knows how she writes, which of her reports to loop in, and what she decided last quarter. That history is what makes it feel like hers.
None of it changes what she is allowed to do. Memory shapes the answers it gives. The credentials behind every call are the same either way, so the same permissions apply no matter who is asking.
Standing identity is right for Dana, because she is the only one using it. It stops being right the moment two people with different access share one agent.
Share it, and standing identity runs out
Same idea, new job: a finance assistant the whole company shares. Marina is the CFO, Leo is an intern, and both ask it for the private Q3 forecast.
Switch between them. Both of them get the private forecast. Your app knew which one signed in, and none of that travelled with the call, so all the checkpoint has to go on is finance-assistant.
Leo could not have pulled that forecast on his own, and the assistant got him in anyway. Take the forecast away from the agent and Marina loses it too. Neither setting is the one you wanted, and that is the tell: the problem is the identity model, not the permission.
Delegated identity: the agent acts for someone
Now the agent keeps its own identity and sends the person along with the call. Try the same two people again.
Marina gets the forecast and Leo is refused. Nothing about the deployment changed between those two calls: same code, same endpoint, same prompt, same tools attached. Each of them just got what they could have reached without the assistant.
Borrowed for one call
Marina's identity rides along with this one request and stops there. The agent does not keep it, and the next call has to carry her again.
It is also not a way to gain access. Carrying Marina lets the agent satisfy a rule that asks for her role. It cannot get her past a rule that denies the call outright. Delegation only ever narrows what a shared agent can do.
It matches yesterday's invoices against the ledger. Nobody is awake to act for.
What the checkpoint can see
agent = invoice-reconciler
No person on the call, so everyone using this agent looks the same.
One identity to check, which is the agent.
Check yourself
An executive's assistant holds two years of her preferences and past decisions, and every call it makes uses the same fixed credentials. Which identity model is that?
The architecture
You do not need one agent per person
A shared agent is just a service. Running it for Marina and running it for Leo is one deployment answering two requests.
One agent per person puts it in the wrong place
You could give people different permissions by registering a separate agent for each of them. Turn up the headcount and see what that costs you.
Every one of those agents runs the same code. Each still needs a key to rotate, grants to review, and someone to delete it the day its owner leaves.
Register the service once
Register the code once as finance-assistant and attach the person to each request instead. Now the headcount can change without anyone touching the agent.
The two identities answer different questions. The agent identity says which service called. The person says who it called for this time.
People change faster than deployments
Here is one ordinary week. Somebody joins, somebody is promoted, somebody moves teams, somebody leaves. Your finance assistant sits there through all of it.
Read the person from the request and none of those four events asks anything of you, because Leo's promotion is his to inherit on his next call. Register an agent for each person and every row on that timeline turns into work for you. The second counter keeps the score.
Switch between the two and replay the week.
…and 92 more agent identities
One service, registered again for every person who uses it.
100 people, and 100 agents to keep track of.
Check yourself
Why run one delegated finance assistant instead of registering an agent for every employee?
The trust boundary
The agent cannot pick who it acts for
If the agent could write “I am the CFO” into its own request, this would be one more prompt instruction a model can talk itself out of. So the person has to be established outside the model.
A name in a header proves nothing
There are two ways to show up without an identity worth trusting. One sends nothing at all. The other sends Marina's address, which anybody could have typed.
Both get refused, for different reasons, and the reason is what lands in the audit trail.
The signature gets checked first
Marina signs in at Okta, and Okta hands back a token that says who she is: her email, her roles, her groups. Nobody typed any of that. Okta signed it, and the signature is checked against Okta's published keys before a rule reads a word of it.
Switch between the two. The signed token opens into three claims a rule can act on. The typed one is just a string, so there is nothing to open and nothing worth trusting.
Both identities land in the audit trail
The record has a field built for this. Every event carries an identity_chain, and a delegated call fills in two hops: the agent that ran, then the person it ran for.
Marina's forecast went through, so it wrote two events. Leo asked for the same forecast and got refused, which wrote one, and his name is on it next to the rule that refused him.
Nobody signed in, so there is no token to sendOktaGoogle WorkspaceMicrosoft Entra IDAuth0
Nothing about a person rides along on this call
There is no person here, so there is nothing to verify.
Nothing. No rule runs, and the tool is never called.
Refused before it goes anywhere
Which one you need
Do two people using this agent get to reach the same things?
That is the whole question. If some of them should be able to call something the others cannot, the person has to be on the request. If everyone gets the same reach, putting them there buys you nothing.
The agent does its own job, with its own fixed permissions
- Nobody is waiting on the other end of the call.
- It runs on a schedule, or reacts to a system rather than a person.
- Everyone who can trigger it should reach the same things anyway.
Nightly reconciliation, a deploy bot, a monitoring agent, and the personal assistant that only its owner ever uses.
One deployment acts for many people, and the person decides what it may call
- One service is shared by people with different access.
- A tool the CFO is allowed to use is one the intern should be refused.
- You need to be able to say who a call was for, months later.
The finance assistant, an internal support copilot, and anything sitting behind a login that people query about their own work.
How Dome does it
One call, four callers, four different endings
Same agent, same tool, same arguments. Pick who is behind the request and watch it move through Dome: where the person joins, where the signature gets checked, and where the answer is decided. Two of these never make it as far as a rule.
Marina signs in, and your app holds her token.OktaGoogle WorkspaceMicrosoft Entra IDAuth0
The agent sends its own token, and Marina's token rides along with it.send_forecast({ "quarter": "Q3", "to": "me" })
Your provider signed her token, so Dome can read her claims.
She holds finance-executive, which is what the rule asks for.
Both identities are on the record.
Try it with one shared HR application
Run the same tool call three times. Once as an HR partner, once as an employee reading their own record, and once as a colleague who should be turned down.