Learn
How agents work
An agent decides which calls to make at runtime. Existing application controls do not always evaluate those individual calls.
Start here
Every agent is code, models, and tools
An agent combines application code, one or more models, and a set of tools. The language, framework, and deployment can vary, but those three parts are consistent.
Three parts
The balance depends on what the agent does.
- A support chatbot may have little code and one model.
- A workflow agent may have more code, several models, and dozens of tools.
Wired into a loop
The agent runtime (code) sends the available context to the model. If the model requests a tool, the runtime executes the call and includes the result in the next model request.
One pass through those steps is a round. If the model is not ready to answer, the loop runs again.
The model chooses the next step
You gave the model a question and three tools. It chose one of them. Your application did not make that choice.
The model can also request more than one tool at a time. Two independent lookups may run together in the same round.
Each new round includes the results from the previous one. The loop continues until the model has enough information to answer.
What stays fixed
The agent starts each run with the same three tools because you configured them.
During the run, the model decides:
- which tools to use and whether to call them together;
- the order and arguments for each call;
- when it has enough information to stop.
Ask the same question again and compare the two routes. The model may reach the same answer with different calls.
The agent's application logic. It handles input, state, and calls.
Given the context so far, the model decides what to do next.
Other systems the agent can call, such as APIs, databases, Slack, or payments.
Agents combine code, models, and tools.
Check yourself
The agent used a different sequence of calls each time. What stayed the same?
Tool access
Does approving a tool control who can use it?
Teams usually approve tools one at a time for a specific agent. Unless the system handling the call enforces that restriction, another agent can still use the same tool.
Four tools, four agents
Each tool was approved for one agent, for a good reason. An HR assistant needs to read HR records. A standup bot needs to post to Slack. A payouts service needs to move money.
But approving the tool does not limit it to that agent. The system handling the call still has to enforce who may use it.
Now give a new agent all of them
This agent can call any tool in any order, pass the result of one call into the next, or request several calls in the same round.
Select two or more tools to see what it can do with calls that teams reviewed separately.
What happens when you add another agent?
These four tools have eleven combinations of two or more, before you count the order or arguments. No one reviewed those combinations.
But the combinations are not the main problem. This agent can use tools that teams approved for another agent.
Add a fifth agent with the same four tools and it gets the same access. The original approval does not follow the agent it was meant for.
To stop the call, the authorization check has to know which agent is making it and run before the tool does.
Select tools to combine.
Four tools, each approved for a different agent, and none of them bound to it.
Existing controls
Test the controls already in place
Suppose the agent is about to move $48,000 to an unfamiliar account.
Choose the controls
Which controls would you normally apply to this request? Turn on any or all four.
Now send it
Send the request and watch each enabled control evaluate it.
What the log does not say
The audit line records the transfer and the 200 response after the fact.
It may not identify the agent, the person behind the request, or the rule that allowed it.
None of these controls made an authorization decision, so the log cannot record one.
transfer({ "amount": 48000, "to": "acct_9931" })Nothing in front of the call yet.
Waiting to send.
No controls yet. Switch some on.
Check yourself
All four existing controls passed, but the transfer still ran. What was missing?
Runtime authorization
Authorize each call before it runs
The check needs to know which agent is calling, what it is trying to do, the arguments it supplied, and who asked. It also has to run before the call reaches the tool.
Choose the available context
Select facts in any order. Watch the decision and which other calls it affects.
Include the person behind the agent
Interactive agents usually act for a person.
If the check knows the agent but not the person who asked, everyone using that agent gets the same permissions. The intern and finance director look identical.
Carrying both identities makes per-person rules possible.
Choose where the check runs
Try all three locations and compare how much each one covers.
Apply controls to each part
Tool calls are the obvious place to add a check, but the agent's code and model calls need controls too.
Model calls also leave the agent. They incur cost and may send private context to an external provider.
transfer({ "amount": 48000, "to": "acct_9931" })The check has no information about the request.
It can only allow or block all calls.
Insufficient context. The transfer goes through.
Check yourself
Where do you put the authorization check so every agent has to pass through it?
How Dome does it
Controls for agent identity, tools, and models
Dome provides shared controls for agent code, tool calls, and model calls.
Agent identity in the Registry
The Registry gives the agent a durable identity.
Rules can name that identity, logs can attribute calls to it, and operators can inspect, version, suspend, or revoke it.
Without an identity, a rule cannot reliably refer to the agent.
Tool calls through the Gateway
Before forwarding a call, the Gateway:
- evaluates the call against the applicable rules;
- adds the backend credential without exposing it to the agent;
- runs guards on the response before returning it to the agent.
Model calls through the Broker
The Broker routes model calls to the provider, evaluates them against the same rules and guards, and records them in the same audit trail.
The audit trail can then attribute model spend and data movement to a specific agent instead of a shared API key.
Shared policy and audit data
The three control points share access, authorization, and audit data.
Each control point evaluates the same rules, so the same request gets the same decision.
The audit trail records the reason for a denial as well as the result.
The Registry assigns an identity to the agent
Every tool call is decided before it runs
The Model Broker routes and evaluates every call
Shared by all three
Access
Which agent, and which person it is acting for
Authorization
The rules, evaluated at the call
Audit
The decision and its reason, kept
Rules, logs, and operators can use the registered identity.
Trace it yourself
Follow an agent request
Select a node to see how the request reaches it, which guards run, and which rules apply. A dashed edge marks a grant to a resource the agent cannot reach.
Routes to 1 model
Try it on an agent of your own
The sandbox tutorial connects an agent and denies one of its calls with a rule you write. It takes about ten minutes.