Field guide 17 · Policy

The Policy Gate

Nothing executes because the agent "decided to." Every tool call is intercepted before it runs, evaluated against explicit policy, and given one of three verdicts. The record is sealed whichever way it goes — including the calls that never happened.

AGENT TOOL CALLwrite · pay · send POLICY GATE deny-by-default rules ACCEPTEDexecutes as asked ESCALATEDhuman approves first BLOCKEDnever executes RECEIPT SEALEDall three verdicts
● Accepted

The call satisfied every applicable rule — scope, authority, data boundary, autonomy cap. It executes exactly as requested, and the receipt records what evidence and which rules allowed it.

◐ Escalated

The call is consequential enough that policy requires a human in the loop. It waits; the approver's identity and decision become part of the sealed record. Delegation with an audit trail, not delegation on faith.

✕ Blocked

The call violated policy and never executed. The attempt itself is still sealed — a blocked action you can prove was blocked is a control; a blocked action with no record is a rumor. See one in the live tool-call demo.

Deny-by-default is the posture, not a feature.

The gate does not look for reasons to stop a call — it requires reasons to allow one. A call that matches no rule fails closed. That inversion is what makes the receipt chain meaningful: silence is never consent.

Policy is data, and the receipt names it.

Each receipt records which policy version evaluated the call. When rules change, old receipts still replay against the rules that were in force — same inputs · same policy · same verdict. See Deterministic Replay.

Illustrative explanation of the gate mechanism; verdict names and rule sets are configured per deployment. Not a certification, customer result, or performance claim.
summit·cognitive   Decision Assurance Infrastructure  ·  demo.summitcognitive.ai