Policy Engine

Policies are the authorization layer for every tool call your agents make. They are evaluated on the backend — inside the MCP pipeline — before any adapter runs, and every decision lands in a tamper-evident ledger.

Where policies sit

Every MCP tool call runs through a five-stage pipeline. Policy evaluation is stage two — after schema validation, before the adapter touches any external system.

MCP pipeline

validate → policy → approval → adapter → audit
           │            │          │         │
           │            │          │         └─ ledger entry + operational log
           │            │          └─ calls Slack / Stripe / HubSpot
           │            └─ pause for /approvals if required
           └─ "authorized" | "escalated" | "denied"

The pipeline is the only caller of an adapter. Tools never receive a raw DB session or user that bypasses this flow — "every MCP call is governed" is a structural property of the system, not a convention.

Policy types

Approval policies

Require human approval before a tool call proceeds. The pipeline returns status: "action_required" with an escalation_id. A reviewer approves in /approvals, and the same payload re-runs with authorization on file.

Cost policies

Per-run, per-agent, per-scope, and per-workspace spend caps. Execution halts when a cap is hit and the decision is logged to the ledger with reason="budget_exhausted".

Data privacy policies

Redact PII, SSNs, card numbers, and anything matching custom regex from tool arguments before the adapter runs. The redacted fields are recorded in the audit log, not the raw values.

Content policies

Filter toxic, biased, or off-brand output generated by an AI node. Combines moderation APIs with your own allow/deny lists.

Compliance policies

Tag tool calls against regulatory controls (EU AI Act, Colorado SB24-205, ISO 42001). Evidence export pulls the matching ledger entries.

Enforcement modes

Each policy runs in one of four modes. You can start any policy in log mode, watch the audit for a week to see what it would have blocked, then promote to block or pause once confident.

Mode	Behavior
`block`	Immediately prevent the action. Adapter never runs. The agent sees a deny decision with the policy id.
`pause`	Halt, create an Escalation row, and route to /approvals. Execution resumes on approve; a deny closes the run.
`alert`	Allow the action but notify the governance team in real time (Slack, email, or webhook).
`log`	Record the decision silently. Useful for shadow policies you are rolling out before enforcing.

Example: Stripe refund

The payments.create_refund tool is registered with requires_approval=True. Even if an agent's scope includes payments.*, the pipeline forces an escalation:

MCP response for a refund that requires approval

{
  "ok": false,
  "status": "action_required",
  "reason": "Tool requires explicit approval.",
  "escalation_id": "esc_abc123",
  "tool": "payments.create_refund"
}

The agent surfaces the escalation ID to the user. An approver visits /approvals, reviews the arguments, and clicks Approve. A follow-up tool call with the same payload finds the approval on file and authorizes; the adapter issues the refund via Stripe; both the policy decision and the outcome are persisted.

Two audit rows per call

Every evaluated tool call produces two records. Duplication is intentional — they serve different audiences.

AccountabilityLedger — integrity-hashed, compliance-grade. Consumed by the evidence export pipeline.
AuditLog — operational per-call record with latency, cost, provider ref, client id. What the product UI queries for "what just happened".

Writing your first policy

Open Policies in the dashboard and click New Policy.
Pick a trigger — a namespace (payments.*), a specific tool, or a condition on arguments (e.g. amount_cents > 50000).
Pick a mode — log to observe, block to deny outright, pause to route to approvals.
Optionally scope to an agent, a workspace, or a set of users.
Save. The policy is live immediately; the next matching tool call runs under it.