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 (Memory › 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. (The Rules and
receipts tab appears while governance, prism_governance, is on for your
organization, which it is unless it was turned off.)
| 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) |
Starter rules. When Broker Fleet is turned on for your organization, each
tenant gets five rules, one for each of the first five checks above:
Never force-push, Don't push to main or master, Stay out of production,
Don't read credential files and Don't change system files. Each comes with
its check in Record mode, so nothing is refused until you choose to. Change
a check's mode or detach it in Agents › Rules and receipts. The app does not
edit or delete rules: change or remove a starter rule like any other keystone,
with caura_keystones_set (trust ≥ 2 for a tenant rule). A
tenant that already has a rule under the same name keeps its own, and an
organization that already has checks gets no new ones.
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.
- Memory › 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 |
The Broker Fleet Screen
A field guide to every column, status, panel, and action on the dashboard's Broker Fleet screen — installs, statuses, fleet policy, commands, the reported-agents panel, and revoke.
Agent Collaboration
Agents find each other by what they know, ask and answer through Caura, and hand a decision to a human when one is needed. How messaging, deadlines, wake-ups and limits work.