Policy compiler

Policy compiler

The Policy compiler turns an authored Policy into a deployable, signed artifact.

Operator authors a Policy → cascade merges org/project/agent levels → compiler emits a Compiled Policy, signs it, and pushes it to the host.

This is the static arm of Policy (what travels to the host and configures the runtime environment), as distinct from the Policy engine which is the hot-path arm.

At a glance

Takes	an authored Policy (Rego rules + Sandbox-spec + cascade levels)
Does	merges the cascade, evaluates Rego via OPA, signs the result with Ed25519
Outputs	a Compiled Policy — signed JSON, one per Sandbox
Triggers	every time Policy changes at any cascade level (org / project / agent)
Where it runs	server-side (control plane)

What it does, step by step

[Operator authors / updates Policy at some level]
        │
        ▼
[1. Cascade merge]
        org defaults  ┐
        project       ├──► strictest-wins merge
        agent         ┘
        │
        ▼
[2. OPA evaluate]
        Run the merged Rego against the Sandbox-spec
        (which targets the agent uses, what data classification, …)
        │
        ▼
[3. Render Compiled Policy]
        Serialize into the canonical JSON shape:
          • pipeline_steps (for the Policy engine)
          • sandbox_config (for Providers — harness/OS/interpreter)
          • metadata (policy_version, issued_at, expires_at)
        │
        ▼
[4. Sign]
        Sign the JSON with TapPass's Ed25519 private key.
        → host can verify authenticity + integrity on receipt.
        │
        ▼
[5. Push to host]
        Send via the signed sync channel to every active Sandbox
        whose policy_version is now stale.
        │
        ▼
[Compiled Policy lands on host]
        → Providers consume it, render target-specific config
        → Policy engine reads pipeline_steps for the hot path

Why "signed"

When the host receives a Compiled Policy, it needs to know:

1. Authenticity — did this really come from TapPass? (Not an attacker on the network injecting a permissive policy.)
2. Integrity — has the JSON been tampered with in transit?

The Ed25519 signature answers both. tappass-host pins TapPass's public key at first install; every push is verified before being applied. Without signing, a network-level attacker could push a fake "everything-is-allowed" Compiled Policy to a Sandbox.

The signature also gates the hot path: the Policy engine refuses to run a Compiled Policy whose signature doesn't verify, even if it's the latest one cached.

Triggers

The Policy compiler runs whenever any of these change:

• Operator pushes a new authored Policy (org / project / agent level)
• Operator applies / removes a Compliance pack
• Org or project defaults are updated (cascades into every child agent)
• Compiled Policy expires (expires_at reached) — re-issue with same content + new TTL

Output is monotonic: every push has policy_version > last_applied_version per Sandbox. The host enforces this (anti-replay).

Where it lives

• Server-side (control plane), alongside the OPA cascade and the agent registry.
• On every Policy change: typical compile time < 100ms (small Policy) to < 500ms (large org-wide cascade with hundreds of agents).
• Caches by (org_id, sandbox_id, policy_version); invalidates on policy_store write.

Related

• Sister engine: Policy engine — runs the hot path; reads what this compiler writes.
• Outputs: Compiled Policy — the signed artifact that travels to the host.
• Quick-starts: Compliance packs — feed authoring conveniences into Policy before compilation.