A policy bundle is the published artifact that carries a workspace's approved rules to the runtimes that enforce them. Authoring, review, and approval happen in the control plane; the bundle is the versioned output that crosses the boundary into enforcement — and only branches that reached the PUBLISHED state are in it.
Why Publication Is a Separate Step
In a governed system, editing a rule and enforcing it must not be the same action. If they were, any author with access to the policy editor could change production behavior instantly, and no reviewer would stand between an experiment and a live agent. Bundling draws that line explicitly: a rule is written, simulated, and reviewed as a draft, then published, and only then does a bundle carry it to the enforcement point. Draft and in-review changes have no route into a runtime.
What a Bundle Carries
- The published rule set for the workspace, at a specific, identifiable revision.
- Scope — which decisions each branch governs, from an entire organization down to a single connector or action.
- Effects — what the runtime should do when a rule matches: allow, warn, deny, or escalate to a human reviewer.
- Integrity metadata that lets a runtime and an auditor agree on exactly which artifact was in force.
Distribution: The Runtime Pulls
Enforcement runtimes fetch the latest published bundle rather than waiting to be pushed to. A pull model has two properties that matter for governance. First, a runtime that cannot reach the control plane still holds the last bundle it synced, so a network partition does not silently disable enforcement. Second, every sync is an event: the fetch is recorded in the audit ledger, which is what makes it possible to answer "which rules was this agent enforcing at 14:32 last Tuesday?" with a record instead of an inference.
Exporting to Engines You Already Run
Many organizations already operate a policy engine and are not looking to replace it. A published bundle can be exported to non-AGT targets so the same reviewed rules can be enforced where they already have a decision point:
| Target | Typical use |
|---|---|
| Open Policy Agent (Rego or bundle) | An existing OPA deployment that already gates service calls. |
| Cedar | Authorization decisions expressed in Cedar's policy language. |
| MCP proxy configuration | Governing Model Context Protocol tool calls at the transport layer. |
An export is not an unconditional translation. When a target cannot express a control faithfully, the export surfaces that as a semantic warning and fails rather than quietly shipping a weaker rule set — a silent downgrade is worse than a blocked deploy, because it looks like enforcement while providing less of it. For how this compares with writing Rego by hand, see Spctre vs Open Policy Agent.
Bundles, Blueprints, and Decisions
A bundle carries the rules; an Agent Blueprint declares the envelope one agent may operate inside; policy enforcement for LLMs is what happens when a specific tool call is evaluated against both. The three are versioned separately on purpose, so a rule change, a scope change, and a runtime upgrade are each independently reviewable and independently reversible.