Policy Gateway — Escepine Docs

The Policy Gateway is the plane's runtime enforcement point: a Cedar decision taken before every tool call, against the full step context. It is not a review step, not an advisory lint, and not a post-hoc report — it is on the only path from planner to executor.

The decision point

planner ──▶ proposed tool call
              │
              ▼
        Policy Gateway (Cedar)
              │
        ┌─────┴─────┐
      ALLOW         DENY
        │             │
        ▼             ▼
   schema gate     halt · park
   executor        decision + context recorded

Property	Semantics
Timing	Before execution, per proposed call
Scope	Full step context: tool, parameters, workflow state, actor
Decision	ALLOW proceeds; DENY halts the step and parks the workflow
Record	Every evaluation is a `policy_eval` event, decision included
Deny path	There is no override path — resolution is human, through the park

Policy attachment

Attachment	Semantics
Step-level `include`	The step declares whether it participates in evaluation; opting out requires an explicit `include: false` — an auditable decision, not an omission
Global set	Workflow-wide policies applying to every participating step
Unset on EXECUTION	Flagged at ingest — undeclared policy posture is an audit gap

Policy structure

Field	Semantics
`policy_id`	Policy identity, referenced by evaluation events
`description`	Human-readable intent of the policy
`rules`	Ordered rules: effect — ALLOW or DENY — with conditions

| Evaluation order | Rules evaluate in declared order; the first matching rule's effect decides | | Default | No matching rule → DENY — the fail-closed posture extends to policy resolution |

Conditions evaluate against the step context the gateway receives: tool identity, parameters, and workflow state. A parameter a policy constrains is a parameter the gateway sees before the call is made — which is the entire point of the placement.

{
  "policy_id": "pol_dd_evidence_readonly",
  "description": "Evidence collection in competitor_deep_dive is read-only: retrieval allowed, writes denied.",
  "rules": [
    {
      "effect": "ALLOW",
      "conditions": [
        { "field": "tool.tool_id", "op": "in", "value": ["web_search", "page_fetch", "doc_retrieve"] }
      ]
    },
    {
      "effect": "DENY",
      "conditions": [
        { "field": "tool.side_effect_class", "op": "neq", "value": "read-only" }
      ]
    }
  ]
}

Excerpt — policy record instance. Structure is contractual; values are per-deployment. The second rule constrains by the tool's declared side-effect class — the registry and the policy set speak the same vocabulary.

Fail-closed posture

An unavailable gateway means no tool call proceeds. Execution does not degrade to unchecked; it halts. The posture is deliberate: a governance layer that fails open is a governance layer that disappears exactly when infrastructure is having a bad day — the day it exists for.

CURRENT ARCHITECTURE NOTE — The Policy Gateway is currently embedded within the Core Execution Engine for single-workflow deployments. It centralizes as a standalone service for concurrent multi-workflow policy routing in production. The evaluation contract above is unchanged by the move; only the network boundary changes.