Skip to content
Agentic Control Plane

Policies & scopes

ACP decides allow / deny / redact on every tool call based on three layered policy axes. This page is the mental model — the dashboard is where you actually configure them.

The three axes

Every /govern/tool-use call is evaluated against three axes of policy, in this order:

1. Tool policies — workspace-wide defaults

Dashboard → Policies → Tool Policies. Workspace-wide allowlists and required scopes per tool. The question these answer: “Is anyone in this workspace allowed to call github.repos.delete? What scope do they need?”

This is the first-class way to disable a dangerous tool for everyone, or require a sensitive scope (github.admin) before a tool can be called.

2. Agent policies — per-tier rules

Dashboard → Policies → Agent Policies. Rules per agent tier: interactive, subagent, background. The question these answer: “What can a background cron agent do that my interactive Claude Code session can’t?”

Typical pattern: lock down background agents tightly (read-only, rate-limited, no destructive ops), leave interactive agents permissive, keep subagents in between.

3. User policies — per-identity overrides

Dashboard → Policies → User Policies. Overrides per user identity. The question these answer: “Alice gets to run stripe.charge.* because she’s in finance; Bob does not.”

Use these for carve-outs, not broad strokes. If you’re writing user policies for most of your team, the rule probably belongs in tool or agent policies instead.

Most-restrictive-wins

When the three axes disagree, the most restrictive decision wins.

Tool policy Agent policy User policy Result
allow allow allow allow
allow allow deny deny (user override)
allow deny allow deny (agent tier restricted)
deny allow allow deny (tool blocked workspace-wide)

Deny always wins. This means tightening anywhere — workspace, tier, or user — immediately tightens everywhere, without hunting through lower layers for conflicting permissive rules.

Scopes

Scopes are short strings that describe tool capabilities (github.pr.write, slack.read, stripe.charge.*). They serve two jobs:

  1. Required on the tool side. The tool policy says “github.pr.create requires scope github.pr.write.”
  2. Granted to the caller. The JWT (or the agent’s tier configuration) carries a set of scopes. If the caller’s scopes don’t cover the tool’s required scope, the call is denied.

Scopes support wildcards: github.* covers github.pr.write, github.issue.create, etc. * covers everything — use with care.

For delegation chains (agent calling agent calling tool), scopes narrow at each hop. See agent-to-agent governance for details.

Audit mode vs. enforce mode

Every policy can be in one of two modes:

  • Audit mode — decisions are computed and logged, but deny is not returned to the caller. Every call proceeds. Use this when you’re introducing a new policy and want to see what would be blocked before actually blocking it.
  • Enforce mode — decisions are honored. deny returns a tool-error string to the agent.

Recommended rollout: start in audit mode for a few days. Look at the Activity log filtered by decision: would-deny. Adjust the policy until the false-positive rate is where you want it. Then flip to enforce.

This is how you avoid the common failure mode where a well-meaning tightening of policy takes down half your agent fleet because the rules didn’t match reality.

PII, prompt injection, and secrets

These are handled by the content-scanning layer, which runs on the tool’s output (and optionally its input). Unlike allow/deny, the primary decision type here is redact — the output is rewritten with sensitive strings replaced.

The three detectors today:

  • PII. Emails, phone numbers, SSNs, credit-card numbers, addresses. Default policy: redact.
  • Prompt injection. Heuristic match against known injection patterns in tool output (especially web fetches). Default policy: flag (log but pass through); set to redact or deny for high-stakes agents.
  • Secrets. API keys, tokens, private keys in tool output. Default policy: redact.

Each detector has per-agent-tier policy. A researcher bot reading public docs can have lax settings; a customer-service bot touching real records should redact aggressively.

What you won’t find here

This page is conceptual. For field-level details — exact JSON schema of policy objects, scope inheritance rules, the API for bulk-importing policies — see the API reference. (Coming soon; until then, the Activity log is the source of truth for what policies actually did on a given call.)