Enforcement Layer

The enforcement layer evaluates passport constraints independently of gate verification. Call POST /api/enforce before any action to get a cryptographically signed allow, request_hold, or block decision.

··

Overview

The enforcement layer is separate from gate verification. While a gate checks identity (is this passport valid?), the enforcement layer checks constraints (is this action allowed given current state?).

This means you can use the enforcement layer without a gate, just issue a passport with constraints and call POST /api/enforce before each action.

allow200

All constraints passed. Action is allowed.

request_hold202

Action requires human approval before proceeding.

block403

A hard constraint was violated. Action is denied.

block wins over request_hold. If any evaluator produces block, the engine terminates immediately and returns block, subsequent evaluators are not run.

API

bash

POST /api/enforce
Authorization: Bearer mod_your_key

{
  "passport_id": "pass_01HABC...",
  "action": "payments:send",
  "target": "https://payments.example.com/transfer",
  "cost_cents": 4500,
  "metadata": {
    "recipient": "vendor_xyz",
    "invoice": "INV-2026-001"
  }
}

response (allow)

{
  "decision": "allow",
  "attestation_id": "enf_01HXYZ...",
  "signature": "base64url...",
  "evaluated_at": "2026-02-24T14:30:00Z"
}

response (block)

{
  "decision": "block",
  "reason": "core:cost:max_cumulative",
  "detail": "Daily spend limit of $100.00 exceeded (current: $97.50, requested: $45.00)",
  "attestation_id": "enf_01HABC...",
  "signature": "base64url..."
}

response (request_hold)

{
  "decision": "request_hold",
  "reason": "core:approval:required",
  "detail": "Action requires human approval",
  "approval_request_id": "appr_01HDEF...",
  "attestation_id": "enf_01HGHI..."
}

Enforcement Constraints (28)

These constraints can produce block or request_hold. Evaluators run in order. block causes early termination. request_hold is collected but doesn't stop evaluation (unless block is later found).

Safety (1-2)

core:safety:fail_closedblock all actions when Supravision heartbeat is stale (>2 min).

core:safety:anomaly_suspendrequest_hold when 5-min action rate exceeds 3x the 30-min baseline.

Temporal (10-12)

core:time:operating_hoursBlock actions outside defined operating hours.

core:time:blackout_windowsBlock actions during specific blackout periods.

core:time:idle_timeout_minutesrequest_hold when no activity for N minutes.

core:time:cooldown_secondsblock when elapsed time since last allow is less than N seconds. Returns retry_after.

core:time:max_ttlblock when session duration (since first enforcement call) exceeds N seconds.

Scope (20-23)

core:scope:domain_allowlistOnly allow calls to specified domains.

core:scope:domain_blocklistBlock calls to specified domains.

core:scope:action_allowlistOnly allow specific actions.

core:scope:action_blocklistBlock specific actions.

Rate (30-33)

core:rate:max_per_minuteMaximum requests per minute.

core:rate:max_per_hourMaximum requests per hour.

core:rate:max_per_dayMaximum requests per day.

core:rate:concurrent_maxblock when pending request_hold approvals meet or exceed the limit. Value: integer.

Cost (40-45)

core:cost:max_per_actionMaximum cost per single action (in cents).

core:cost:max_cumulativeMaximum cumulative spend within the configured window.

core:cost:max_per_dayMaximum daily spend. Resets at UTC midnight.

core:cost:max_per_weekMaximum weekly spend. Resets Monday UTC 00:00.

core:cost:max_per_monthMaximum monthly spend. Resets first of month UTC. Value: integer (cents).

core:cost:max_totalMaximum lifetime spend. Never resets.

Approval (50-52)

core:cost:approval_thresholdActions above this cost (cents) require approval (request_hold).

core:approval:requiredAll actions require human approval (request_hold).

core:approval:for_actionsSpecific actions require approval (request_hold).

Data (60-63)

core:data:read_onlyBlock any write, delete, or mutation operations.

core:data:no_pii_exportBlock actions that would export personally identifiable information (PII).

core:data:no_secrets_exportBlock outbound data containing API keys, tokens, or passwords.

core:data:redact_pii_in_logsPost-decision flag: redact PII from attestation logs. Always passes.

Recorded Terms (12)

These values are embedded in signed attestations for downstream billing, SLA compliance, and settlement systems. They never influence the enforcement decision, they always pass. They are not user-configurable in the passport issuance UI.

Cost, Config Flags (46)

core:cost:purchase_protectionConfig flag that activates the purchase detection pipeline. Does not block.

Pricing (70-74)

core:pricing:per_call_centsPrice per API call.

core:pricing:per_minute_centsPer-minute pricing.

core:pricing:per_request_centsPer-request pricing.

core:pricing:modelPricing model: per_call, per_minute, per_request, flat.

core:pricing:currencyCurrency code (default: USD).

SLA (80-81)

core:sla:uptime_basis_pointsGuaranteed uptime in basis points (9990 = 99.9%).

core:sla:response_time_msP95 response time guarantee in milliseconds.

Platform Fee (90-91)

core:platform_fee:basis_pointsPlatform fee as basis points of the transaction.

core:platform_fee:recipientFee recipient address.

Volume Control (92-93)

core:volume_control:modeSampling/routing strategy for downstream systems.

core:volume_control:sample_rateSample rate between 0 and 1 (e.g. 0.1 = 10%).

Cumulative State Tracking

The enforcement layer maintains per-passport, per-window counters for spend and rate limits. These are automatically reset at UTC boundaries.

session

daily

weekly

monthly

rolling

The daily window resets at UTC midnight. weekly resets Monday UTC 00:00. rolling is a sliding window.

MCP tools for cumulative state

get_cumulative_state

Read current spend and rate counters for a passport.

json

{ "passport_id": "pass_01HABC..." }

reset_cumulative_state

Reset counters, optionally by window type.

json

{
  "passport_id": "pass_01HABC...",
  "window_type": "daily"
}

Signed Enforcement Attestations

Every enforcement decision produces a signed enforcement attestation, a tamper-proof record with sequence chaining that prevents gap-filling attacks.

enforcement_attestation.json

{
  "id": "enf_01HXYZ...",
  "passport_id": "pass_01HABC...",
  "action": "payments:send",
  "decision": "allow",
  "cost_cents": 4500,
  "evaluated_at": "2026-02-24T14:30:00Z",
  "constraints_evaluated": [
    { "key": "core:cost:max_per_action", "result": "PASS" },
    { "key": "core:cost:max_cumulative", "result": "PASS" },
    { "key": "core:rate:max_per_day", "result": "PASS" }
  ],
  "sequence": 42,
  "prev_attestation_id": "enf_01HWXY...",
  "signature": "base64url..."
}

Commerce Integration

When a passport has core:pricing:* constraints (from a published catalog), the enforcement layer automatically issues a consumption attestation on allow. This enables bilateral metering without extra code.

The hook runs after enforcement: enforce → allow → check if permission has core:pricing:* → if yes, issue consumption attestation automatically.

Passport-Only Enforcement, Use the enforcement layer without a gate.
API Reference, Full endpoint documentation.
Billing & Metering, How enforcement connects to consumption attestations.

Trust Profiles Supravision