Skip to main content

Policies & Approvals

Every tools/call is evaluated before dispatch (and results again after) against your tenant's policy rules, managed at Governance → MCP Gateway → Policies. The gateway syncs rules continuously, so changes take effect within seconds — no deploys.

Matching: who, what, where​

Each rule scopes itself along any combination of:

DimensionExample
Upstreamgithub, *
Tool (glob)*delete*, notion.notion-create-*
User emails["contractor@…"]
User roles["member"] — from tenant membership
Teams["support"]
Agent["cowork-research-agent"] — which agent profile made the call

That last one matters: the same human gets different rules depending on which agent is acting for them.

Actions​

Access control

  • deny — block the call, tell the caller why
  • allow — explicit allow (useful below a broad deny)
  • require_approval — park the call for a human reviewer (see below)

Data protection

  • redact_args / redact_result — strip named keys from arguments or results
  • dlp_scan_args / dlp_scan_result — run DLP scanners (PII, credentials) and record findings
  • dlp_block_args / dlp_block_result — block when scanners hit
  • egress_block — block results containing URLs/hosts outside an allowlist

Budget & abuse

  • rate_limit — N calls per window, per matching scope
  • cost_cap — cumulative USD cap per window (per-call cost assigned by rule)

Supply-chain defense

  • deny_drift — block tools whose fingerprint changed since last approved (details)
  • risk_deny — block tools with unacknowledged risk flags at/above a severity

Rate-limit and cost-cap counters are shared across gateway replicas, so limits hold under horizontal scale.

Precedence: deny > require_approval > redact > allow. The most restrictive matching rule wins.

Approval workflow​

When a require_approval rule fires, the call parks and a reviewer decides at Governance → MCP Gateway → Approvals: full context — who, which agent, which tool, the exact arguments — with approve/deny. Each rule sets a timeout and what happens on expiry (auto_decision_on_timeout, typically deny).

Approval lifecycle events (requested, granted, denied, timed out) flow into Incident Notifications, so reviewers get an email or webhook the moment something parks — one rule can fan out to multiple channels.

The caller experience: the agent's tool call simply waits (the gateway polls until decided or timed out), then proceeds or gets a structured denial. No retry choreography needed in the agent.

A starter rule set​

A pattern that works for most tenants on day one:

  1. deny on *delete*, *drop* across all upstreams — pure destructive verbs off the table.
  2. require_approval on payment and outbound-communication tools (stripe.*, *send*) with a 15-minute timeout, deny on expiry.
  3. dlp_scan_result on everything — visibility first; upgrade hot spots to dlp_block_result once you've seen real traffic.
  4. rate_limit 100 calls / 5 min per agent as a runaway-loop backstop.
  5. deny_drift everywhere — free protection, fires only when an upstream changes a tool under you.

Every decision — allow, deny, redaction, approval, the rule that fired — is recorded in the audit log.