Policy IR and compiling everywhere

One document

An ARC1 policy is a versioned, declarative document that holds metadata only. Credentials appear as references to a vault or the environment, and anything shaped like a credential is refused when the document is read. A policy holds between 1 and 64 controls and binds them to between 1 and 32 targets.

There are fifteen kinds of control: models, tools, MCP servers, tokens, input tokens, budget, egress, sensitive data, sessions, reasoning, accounts, substitution, execution limits, routing and cache. Each runs in one of three modes. Observe counts, warn tells the person and continues, and enforce stops.

Twenty-two targets

A target is one enforcement point. The compiler knows twenty-two kinds, among them managed settings for Claude Code and Codex; Kong; Azure API Management, including its MCP policies; LiteLLM, globally and per team; Amazon Bedrock Guardrails; Apigee; Cloudflare AI Gateway and Cloudflare Gateway; Portkey; F5 AI Gateway; NGINX Gateway Fabric; Agent Router, formerly Envoy AI Gateway; Zscaler Internet Access; and Cisco and Palo Alto Networks security services. The ARC1 Gateway receives the same policy as a signed pack.

For each target, a capability table states control by control whether it can enforce, can only observe, or cannot express the control at all, and why. The hub publishes those tables, so a platform team can see what a target will refuse before writing the rule.

Deterministic, or refused

Compilation is a pure function: no clock, no network, no files and no signing. The same policy and bindings produce the same bytes and the same digests every time, so a reviewer approves a digest, not a description.

Where a target cannot express a control, compilation refuses instead of approximating, and a target with any error publishes nothing. Kong refuses lowest-cost routing, Azure API Management refuses latency-based routing, and gateways that cannot rewrite a body refuse redaction. A control in observe or warn mode is never turned into a denial on a target that only knows how to block. Every compiled result states that it needs approval, has not been executed and is not yet verified as enforced.

Apply, read back, watch

After a second person approves the exact plan, the hub applies it once, within 30 minutes, and only if the target has not changed since the plan was made. It then reads the target back, compares by digest, names the configuration paths that differ, and repeats on a schedule, every 15 minutes by default, reporting in sync, drifted, stale or unreachable. A matching readback shows that the configuration agrees with the approval. It does not show that traffic was enforced. Governance describes the approval.

For the ARC1 Gateway, the hub signs a policy pack that the gateway verifies against a pinned hub key, refreshes every 30 seconds and holds for at most an hour. If the hub becomes unreachable, the gateway keeps enforcing its last verified pack for a grace period the policy states, at most 72 hours, and revoking the policy ends the grace at once.

Managed coding agents

For Claude Code and Codex, the hub resolves each machine’s effective policy from its organization, team, person and repository layers and signs it. The machine verifies the signature, compiles the policy again itself, refuses any result whose digest differs, and installs it as managed settings. Coverage then shows whether each machine is current, lagging, diverged, drifted or in conflict. Those are the machine’s own reports, not proof.

Policy as code LAB

A command-line plan and apply, and a Terraform provider with resources for policies, allowances, connections and rules, let platform teams keep ARC1 policy in their own repositories. Apply creates a pending proposal and never approves it. Approval stays with a second person in ARC1, and destroying a resource cannot delete approved history.

Where it stands

LIVE: in the released product and running on our hosted production deployment, with synthetic data. LAB: built or being built, and run only in our lab or against a vendor’s documented interface. NEXT: designed, not yet built. How we use these words.