Where Agents Reach and Which Rules They Keep
What the Caura broker can record about the agents on your organization's machines — the programs, hosts, MCP servers and sensitive files their tool calls reach, and whether each call kept the rules you attached a check to. How to turn each on, what is and isn't sent, and where the results show.
A receipt proves which rules were delivered to an agent's session. It doesn't say whether the agent then kept them. The broker closes that gap in two ways, both set per organization:
- Where agents reach (on unless you turn it off): for each tool call, the programs it ran, the hosts and external MCP servers it contacted, and whether it touched credential or system files.
- Rule checks (only for rules you attach a check to): whether each tool call kept the rule, and, if you choose, refusing a call that would break it before it runs.
Both need brokers in fleet mode (onboarding). Both are checked on the machine. The command, its arguments, file paths, and the path or query of a web address are never sent.
Where agents reach
The switch is Settings › Agent monitoring › Record where agents reach, on by default. The page is there once Broker Fleet is on for your organization, and changing it needs the manage governance permission (org admins have it).
Every broker in the organization picks the setting up with its fleet policy, within a couple of minutes. While it's on, each tool call's audit entry names what the call reached:
| What | Example | Read from |
|---|---|---|
| Programs | git, psql, kubectl | the shell command, read the way the broker's write gate reads it: past wrappers such as sudo and env, and into sh -c and eval |
| Hosts and services | api.stripe.com, db.prod.internal, web search | URLs in a command or a web tool, user@host and host:path remotes, --host values |
| MCP servers | github, linear | the tool's name (mcp__<server>__<tool>) |
| Sensitive files | credential files, system files | a file tool's path, classified on the machine |
Only the names leave the machine, at most eight of each kind per call. They are in the machine's local audit log before they upload.
Where it shows: Home › What they reached and the audit trail (Prism › Audit trail), for people who can view the organization's audit log.
Turn it off and brokers stop recording it at their next policy refresh. Entries already uploaded stay in the audit trail.
Rule checks
A rule is a keystone: prose an agent reads at session start. A check is how the broker tests a tool call against that rule. Attach one in Agents › Rules and receipts › How rules were kept: pick the rule, the check, its list if it takes one, and the mode.
| Check | A call breaks it when it… | List |
|---|---|---|
| No force-pushes | runs git push with --force, -f or a +refspec | — |
| No pushes to protected branches | runs a git push that names a protected branch (a bare git push isn't counted, since git decides where it goes) | branches, default main, master |
| No production access | names production in a cluster, project or profile flag, a Terraform workspace or a host | names for production, default prod, production |
| No credential files | reads or writes keys, tokens or .env files | — |
| No system file writes | writes under /etc, /usr and the like | — |
| Only approved MCP servers | calls an MCP server not on the list (Caura's own is always allowed) | approved servers (required) |
| Only approved hosts | reaches a host not on the list (*.example.com covers its subdomains) | approved hosts (required) |
Modes:
- Record notes whether each call kept the rule and lets it run.
- Block refuses a call that would break the rule, before it runs. The agent is told why, by the rule's title: Blocked by your organization's rule in Caura: Never force-push a shared branch.
Some calls can only be checked after they run: Codex's and Cursor's calls outside their shell. These are recorded as checked after, are never refused, and count as broken, not blocked.
What counts: a session is checked only against the rules it was delivered at session start, the same rules its receipt lists. A broker restarted in the middle of a session doesn't know that session's rules until its next start, so it checks nothing for it until then.
Where it shows:
- Agents › Rules and receipts › How rules were kept: per rule over the last 7 days, how many calls were checked, broken and blocked.
- Home › Rules kept: the same totals for the period you pick.
- Prism › Audit trail: each call's verdict.
A rule with no check still has its receipt. A check covers only what it names, so "kept" means the call didn't break that check, not that the agent followed the rule's whole intent.
What is sent, exactly
For a call a check looks at, the audit entry carries the rule's id, the check, whether the call broke it and whether the broker refused it. The call itself is checked on the machine and isn't sent. The broker's privacy note §1.4 is the full list.
Who can do what
| Action | Permission |
|---|---|
| Turn reach recording on or off, attach or change a check | manage governance (org admins) |
| See reach, rule tallies and verdicts | view audit log |