Platform
Governance & audit
Authority is scoped at the database, every agent call is recorded, every agent write is held for a human, and unusual agent activity raises an alert to the workspace that owns the grant.
Row-level security, per actor
Security lives at the database layer. Every table carries row-level security (RLS) policies, and access is scoped per actor — a person, a personal-access-token principal, or an agent principal each sees only the rows their identity is entitled to. The agent door never falls back to a service-role bypass for a caller's reads or writes: an agent's queries run through an RLS-bound client, with an additional explicit organization binding on every org-scoped query so a grant issued for one workspace can never reach another's rows.
Human and judge gates on published work
No model writes to a client-facing surface unsupervised. AI-drafted findings move from draft to review to published only through documented human or judge review. The platform's write paths for agents inherit the same posture: an agent's write is held for a human unless a workspace has explicitly, and provably, opted a specific grant into direct apply (see the approval queue below).
The per-call audit trace: agent_usage
Every agent-door tool call writes exactly one row to agent_usage — success,
denial, invalid input, not-found, a held write, or an error. This is the door's own audit
ledger. (It is distinct from the REST/token-door's HTTP request log; the agent door records
agent_usage.) Each row carries:
| Field | What it records |
|---|---|
surface | The door the call came through (mcp for the agent door). |
tool_name | The tool invoked. |
status | Outcome vocabulary — ok, permission_blocked, invalid_input, not_found, rate_limited, pending_approval, and others. |
organization_id, grant_id, session_id | The authority the call ran under. |
run_id | The session's establishment run, for rollup. |
actor_type, actor_id | The acting principal (agent, and the grant it belongs to). |
input_summary, output_summary | Bounded, redacted summaries of the call — erasable. |
latency_ms | How long the call took. |
ts | When it happened. |
The row also carries a billed_cents field reserved for future metering; it is
unset for agent-door calls today, which are not billed.
Your team reads these traces in the dashboard — the Agent Oversight console's
Activity view lists agent_usage and its run-level rollups for your workspace. No
MCP tool exposes the audit ledger to agents; it is a human-facing accountability surface, not
an agent-readable one.
The default-hold approval queue
Agent writes are parked in an approval queue and applied only after a workspace admin approves them, with the target re-validated at apply time. The full lifecycle is documented under Write approvals.
Anomaly detection — alert-only
The door watches each grant's own activity for three anomaly signals: a rate spike, a burst of capability-blocked calls, and a new client identity appearing on an established grant. When one fires, it raises an alert to the owning workspace's own admins. Anomaly detection is alert-only — it does not throttle, block, or revoke on its own. Enforcement is the job of the rate limits below.
Rate-limit enforcement
A four-dimension rate-limit matrix (per-session, per-grant, per-organization, per-tool) enforces operational ceilings on agent traffic. These are abuse controls, not a billing meter — the numbers and behaviour are documented under Rate limits.