Runtime Policy Patterns.

Why policy belongs at runtime.

Most platforms allow the agent action to proceed and audit it after. Audit is not enforcement. Enforcement is the policy refusing the action at execution time, with the predicted blast radius attached.

A copilot suggests; the human decides. A control layer constrains; the action either falls within bounds or does not execute. Both belong in production. The latter is non‑negotiable for autonomy.

"Before a human or agent acts, predict blast radius from the runtime model, not from a snapshot, not from a correlation, from the live causal state of your stack."From the Context & Control Model

The five core primitives.

Start here. These five cover most of the failure surface for agent‑driven operations and define the vocabulary the rest of the reference uses.

Blast radius bounded.

The percentile of traffic, services, or user transactions predicted to be affected if the proposed action executes. Policy refuses any action whose predicted blast radius exceeds the bound declared for the action type, the service, or the deploy window.

Schema drift refused.

Destructive database migrations and data‑model changes require explicit human approval before execution. Drift is detected against a declared schema contract, not inferred after the change lands. Reversal paths are part of the policy verdict.

Network boundary.

Policy gates prevent agent actions from crossing declared trust zones (internal → external, staging → production, service → infrastructure) without explicit approval. The trust zone graph is part of the runtime model.

Sandbox grants.

Write access provisioned to agents with explicit scope (which APIs, which resources), an expiration timestamp, and revocation triggers tied to action outcome. A grant is a contract, not a flag.

Signed audit.

Every executed agent action is cryptographically signed, logged with its policy verdict and the runtime state at decision time, and persisted as replayable evidence, usable for compliance review, post‑incident learning, and agent calibration.

The dozen, in full.

The five primitives above plus seven that round out the pattern set. Most platforms implement two or three. The full dozen is what production autonomy requires.

• Reversible by default. Actions are rejected unless an automatic reversal path is declared and tested.
• Memory write. Every executed action appends to the runtime memory so the next incident inherits its outcome.
• Rate limiting. Per‑agent, per‑service, per‑action‑type budgets that throttle bursts before they compound.
• Quorum gates. High‑blast actions require N‑of‑M approvals (human or peer agent) before execution.
• Identity binding. The signed audit record names the agent identity, the policy version, and the human chain of authority delegated through.
• Drift detection. Continuous comparison of declared contracts against observed runtime state; the policy refuses actions whose preconditions no longer hold.
• Kill switch. A single first‑class primitive that halts all autonomous execution immediately, with a defined recovery procedure.

Policy in the incident lifecycle.

Policy binds the four stages where autonomous systems fail. Each stage owes the next a signed record.

Propose.

The agent reads the runtime model, frames an action, and attaches the predicted blast radius from the dependency graph. No proposal is valid without a blast prediction.

Evaluate.

Policy iterates over every primitive that applies (blast, schema, network, sandbox, rate, quorum) and returns a verdict with confidence. The verdict is the contract for what executes.

Enforce.

Approved actions execute with their sandbox grant; refused actions return to the agent with the failing primitive named, not just a generic denial. The agent learns where the boundary is.

Remember.

Outcome (success, partial, rollback) writes back to the runtime model and recalibrates the policy bounds for next time. Without that memory write, the lesson from every incident walks out the door.

Phased adoption.

No team flips on full autonomy on day one. Most don't need to. The four‑stage rollout we see work in practice:

Stage 1 · Advisory.

Agents propose, policy evaluates, humans execute. You measure two things: how often the policy verdict matches what the human decides, and how often the predicted blast matches the observed blast. Calibrate before promoting.

Stage 2 · Constrained execution.

Allow agent execution within tight bounds: reversible actions only, blast radius under a low percentile, sandbox grants with short expirations. Measure the rate of policy refusals, not just successes. A runtime that never refuses isn't doing its job.

Stage 3 · Green‑path autonomy.

Expand bounds for actions on services with sufficient memory in the runtime model. The model knows which services have predictable failure modes. Untested services stay constrained.

Stage 4 · Continuous calibration.

The runtime model is a learning system. Treat calibration as a quarterly engineering review, the same way you would a load test or a security audit. Runtime models that don't recalibrate decay.

Audit as a byproduct.

When every action is signed at execution with the policy verdict and runtime state attached, audit becomes a query, not a project. The same primitive that protects production produces the compliance evidence (SOC 2, ISO, internal governance) without a parallel reporting pipeline.

This is the quiet payoff of runtime policy. The same layer that says "no" at the right moment also tells the auditor exactly what was decided, by which version of which policy, on behalf of which human.