3 · Govern

Everything in this stage attaches to the AI System you created in Deploy — because the system is a resource group, every control the platform has can be scoped to exactly it. You don’t govern “the gateway” and hope your agent is covered; you govern support-copilot.

Two composition rules govern the governing, and they never bend:

Restrictions compose min-wins, downward. Your team’s budget, the org’s rate limit, a parent’s parameter clamp — all apply to your system automatically, and nothing you set on the system can loosen them. You can only add tighter rules of your own.
Resources compose additively, gated by inheritance. What the system may use is its own bindings plus (if inherit_resources is on) its ancestors’ — which you already decided in Deploy.

So the governance you add here is the system-specific layer on top of an org-wide floor. That’s what makes it safe for a developer to self-serve most of this stage.

Guardrails — what may be said

Content checks on inputs and outputs: prompt-injection and jailbreak detection, PII (redact or block), secrets, toxicity, banned words. A guardrail config lists the groups it applies to — add your AI System’s group id and every LLM, MCP, skill and A2A call the system makes is checked inline. A blocked input returns 403 with guardrail_blocked; the provider never sees the request.

For support-copilot: PII redaction (not blocking) on inputs is usually right for a support context — customers will paste their own details — plus injection/jailbreak blocking, and an output check so the agent can’t leak what a tool returned.

→ Guardrails — check types, surfaces, streaming behavior, fail-open vs fail-closed.

Tool policies — what may be done

Guardrails inspect content; policies inspect actions. Argument policies pattern-match the arguments of MCP tool calls (deny DROP TABLE through the SQL tool, deny SSRF-shaped URLs through the fetch tool); semantic policies classify the intent of a call. Both bind to your system’s group and return a 403 with the policy verdict — logged, like everything, on the audit row.

You can also filter which tools of a bound server the system sees at all: the CRM server may expose twelve tools while support-copilot gets four. Discovery (tools/list) is filtered per group, so the model is never even shown what it can’t call.

→ Argument & semantic policies · capability filters

Budgets, quotas & rate limits — how much

Set the system’s own ceiling: daily/monthly dollar budgets, token quotas, requests-per-minute, concurrency. Your parent team’s limits still apply — the effective limit is the minimum across the chain.

For an agent, two limits earn their keep fast: a daily dollar budget (a looping agent is a spend machine; see the runaway-agent pattern for what happens next), and a concurrency cap (a stuck retry loop shouldn’t hold every slot the team has). Exceeded limits return 429 with Retry-After; approaching thresholds surface early via the X-Usage-Warning response header your agent can watch.

→ Budgets, quotas & rate limits

Approvals — when a human decides

Mark specific tools approval-required for the system’s group, and calls to them park with 202 until a group member approves or denies — the pattern your agent already handles from Develop. For support-copilot, the refund skill is the obvious candidate: reads are free, money moves through a human.

→ Tool approvals

Agent grants — who the agent is allowed to be

If you gave the system an agent identity in Deploy, write its grants now. The model is actions, not access — (action_type, target, effect) with default-deny:

A=agent-01K0...   # support-copilot's agent identity

# Read the CRM freely
curl -X POST http://localhost:5050/v1/admin/agent-identities/$A/grants \
  -H "Authorization: Bearer $ADMIN_TOKEN" -H "Content-Type: application/json" \
  -d '{"action_type": "mcp_tool", "target": "crm:*", "effect": "allow"}'

# Refunds need a human
curl -X POST http://localhost:5050/v1/admin/agent-identities/$A/grants \
  -H "Authorization: Bearer $ADMIN_TOKEN" -H "Content-Type: application/json" \
  -d '{"action_type": "skill_exec", "target": "customer-refund", "effect": "approval_required"}'

Tool risk classes (read_only, idempotent, destructive, open_world) derive from MCP annotations, and a grant can deny by risk class — with a conservative default: an unannotated tool counts as destructive + open_world, so deny_tool_risk: ["destructive"] blocks exactly the tools nobody has assessed.

Autonomy — the master dial

Independent of everything above, the system carries an autonomy level: autonomous → approval_required → restricted (read-only) → suspended (everything denied, with a specific error). It resolves min-wins across the hierarchy and the acting agent, which is what makes “suspend this AI System” mean something — it suspends every actor inside it. In Assure you can arm a response policy that tightens this dial automatically when the system drifts.

Before you change anything in production: replay

Once the system has traffic, every governance change you’re considering can be tested against reality first. Replay re-evaluates the authorization decisions of a stratified sample of the system’s real recorded runs under the candidate configuration and diffs the verdicts — would this change deny a step that used to succeed? would it add an approval? — without dispatching anything: no tool fires, no token is spent, structurally.

That is the release question (“would this change govern my traffic differently?”), answered deterministically, before the change lands.

→ Replay

What you have at the end of this stage

A system that can only say what it should, do what it should, spend what it should — with the risky 5% routed through humans, and every decision (allow, block, redact, park, approve) landing on the audit row with a correlation id. Now watch it run:

4 · ObserveMission Control, cost attribution, usage and logs — filtered to your system.

Governance sectionThe full reference for every control this page attached.