Developers · Tool policy
A policy is a formal document, not a convention: which tools exist for an agent, what each may do, how secrets are handled, and what must be logged. The runtime enforces it at execution time, so the policy you review is the behavior you get.
The four surfaces
Tools come from an approved registry: pinned server identity, validated configuration, and a typed projection of what the tool exposes. Configuration drift is detected before execution, not after.
Grants are typed across tools, network, and secrets, with explicit deny and override semantics. query on a dashboard is a different grant from list on a cluster, and neither implies a write.
Credentials are held and injected by the runtime; they never enter the agent's context. Network egress is allowlisted per tool, with the host denying by default.
The policy declares what must be logged for each grant. An action that can't satisfy its audit obligation doesn't execute, logging is a precondition, not best effort.
An out-of-policy call never runs. The denial is written to the ledger with the same fidelity as an execution, so attempted overreach is visible, not silent.
Platform-wide constraints, runtime policy, and per-agent policy compose in a defined order, and the console can answer "why allowed" and "why denied" for any call.
In practice
Read-only observability for an incident-triage agent: two tools, two capabilities, per-call audit. Everything not listed is denied, which means reviewing the policy is reviewing the blast radius.
{
"name": "observability-readonly",
"tools": {
"grafana": { "caps": ["query"] },
"kubernetes": { "caps": ["list", "describe"] }
},
"secrets": "runtime_held",
"egress": "allowlist",
"audit": "every_call"
}
Two calls inside the grant execute and are recorded; one outside it is denied and recorded. The agent's view and the auditor's view are the same view.
Declare tools, capabilities, secrets handling, and audit obligations once, and every agent call is checked against it, forever.