Learn
How agents borrow your identity
A shared agent should not give an intern the CFO's access. The agent needs to know who it is acting for on each request.
The two models
Two ways an agent can act
An agent can act as itself or for a person. That choice decides whether its access stays the same or changes depending on who is using it.
Standing identity: the agent acts as itself
A reconciler runs at 2am. No one asked it to run, and no one is waiting for the result, so it uses the permissions assigned to the job rather than a person.
There is only one identity to check: the agent. That is standing identity.
Most unattended automation works this way. Giving a nightly job someone's permissions would only give it more access than it needs.
Personal memory does not change permissions
Dana's assistant knows how she writes, who she works with, and what she decided last quarter. That history is what makes it feel like her assistant.
None of that changes what Dana may access. Memory shapes the answers, but every call still uses the same credentials and permissions.
Standing identity is right for Dana, because she is the only one using it. If two people with different access share the agent, standing identity no longer works.
What happens when people share the agent?
Now take a finance assistant shared by the whole company. Marina is the CFO, Leo is an intern, and both ask for the private Q3 forecast.
Switch between them. Both get the private forecast because the authorization check only sees finance-assistant.
Leo could not access the forecast on his own, but the assistant gives it to him. Remove the agent's access and Marina loses it too. The permission is not the problem; the request is missing the person using the agent.
Delegated identity: the agent acts for someone
Now the agent keeps its own identity and includes the person on the request. Try Marina and Leo again.
Marina gets the forecast and Leo is refused. The code, endpoint, prompt, and tools are the same for both calls. Only the person on the request changes.
Borrowed for one call
Marina's identity is attached to this request only. The agent does not keep it, so the next call has to include 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 cannot give the agent access Marina does not already have.
It matches yesterday's invoices against the ledger. No one is awake, and it is not acting for anyone.
What the authorization check can see
agent = invoice-reconciler
There is no person on the call, so everyone using this agent looks the same.
The authorization check only needs the agent identity.
Check yourself
Dana's assistant remembers her preferences but uses the same credentials on every call. Which identity model does it use?
Agent deployment
You do not need one agent per person
A shared agent is one service. Running it for Marina and running it for Leo means the same deployment handles two requests.
What if you register one agent per person?
You could give people different permissions by registering a separate agent for each of them. Choose a headcount to see how many agents that creates.
Every copy runs the same code. Each one still needs a key to rotate, grants to review, and someone to delete it when its owner leaves.
Or register the service once
Register the code once as finance-assistant and attach the person to each request instead. The headcount can change without anyone changing the agent.
The two identities answer different questions. The agent identity says which service made the call. The person says who it made the call for.
What happens when employees change roles?
Here is one ordinary week. Someone joins, someone is promoted, someone moves teams, and someone leaves. The shared finance assistant stays the same through all four changes.
When the request includes the person, Leo gets his new access on his next call. With one agent per person, every change creates work for the platform team.
Switch between the two approaches and replay the week.
…and 92 more agent identities
One service, registered again for every person who uses it.
100 people require 100 registered agents.
Check yourself
Why use one delegated finance assistant for the whole company?
Verify the person
The agent cannot pick who it acts for
The agent cannot simply write “I am the CFO” into its own request. An identity provider has to verify the person outside the model.
Does an email address prove who made the request?
There are two ways to arrive without a verified identity. One request sends no person at all. The other sends Marina's email address, which anyone could have typed.
Dome refuses both requests for different reasons and records the reason in the audit trail.
What changes when Okta signs the identity token?
Marina signs in at Okta, which returns a token with her email, roles, and groups. Okta signs the token, and Dome checks that signature against Okta's published keys before a rule reads any of the claims.
Switch between the typed address and the signed token. The rule can read the signed claims. It cannot trust the address on its own because there is no proof of who supplied it.
What does the audit trail record?
Every event has an identity_chain. For a delegated call, it records the agent that ran and the person it acted for.
Marina's request produced an attempted event and a completed event. Leo's request was refused, so the event also records the rule that denied it. Switch between them to compare the records.
No one signed in, so there is no token to sendOktaGoogle WorkspaceMicrosoft Entra IDAuth0
This call does not include a person
There is no person to verify.
No rule runs, and Dome never calls the tool.
Dome refuses the request before it goes anywhere
Which one you need
Should everyone who uses this agent have the same access?
Use delegated identity when the person changes what the agent may access. Use standing identity when every caller should have the same access.
The agent does its own job, with its own fixed permissions
- No person initiates the call or waits for its result.
- 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.
- The rules allow the CFO to use a tool and deny the intern.
- 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
What happens when each caller makes the same request?
The agent, tool, and arguments stay the same. Choose a caller and follow the request through Dome to see where the person is added, where Dome checks the signature, and where the rule makes its decision. Two of the requests stop before a rule runs.
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.