Skip to main content

Policy Interoperability & Provenance

FleetForge is multi-engine by design: Rego→Wasm powers guardrails today, and OPA bundle ingestion plus Cedar policy translation keep customers on familiar tooling. This page explains how mixed policy packs load, how fleetforge-ctl policy inspect publishes provenance for every import, and how upcoming Biscuit/VC capability credentials extend enforcement into portable receipts.

Policy engine matrix​

SurfaceEngineStatusNotes
Runtime guardrailsRego compiled to Wasm✅Default pack (policy-packs/default/) compiled at build time; runs inside executor + ingress hooks.
Runtime guardrails (OPA bundle loader)Rego bundle → Wasm at load⚙️ FGLoad pre-existing OPA bundles, compile to Wasm on ingest, and attach provenance metadata before promotion.
Runtime guardrails (Cedar)Cedar policy → adapter microservice⏳ NextTranslation layer posts Cedar JSON to the policy microservice; downstream roadmap item.
TrustOps gatesRego→Wasm today, Cedar planned⚙️ FGChangeOps already consumes Rego packs; Cedar translation shares provenance path.

Importing OPA bundles​

# Publish an existing bundle with provenance metadata
fleetforge-ctl policy import \
  --engine opa-bundle \
  --bundle ./policies/llm_guardrails.tar.gz \
  --name llm-guardrails-v3 \
  --signer "[email protected]"

# Inspect the pack before promotion
fleetforge-ctl policy inspect llm-guardrails-v3

fleetforge-ctl policy inspect emits:

  • hash + signature for the bundle
  • engine (opa-bundle), compiled Wasm artifact, and manifest location
  • provenance document stored alongside the pack (policy-packs/provenance/*.json)
  • Status & Acceptance link if the pack is tied to a roadmap milestone

During import, FleetForge records:

  • pack metadata (name, version, declared controls)
  • Git repo/commit (if provided)
  • signer profile (docs/governance/signer-profiles.md) used to verify the import
  • SCITT receipt identifier when transparency mode is enabled

Cedar example (alpha)​

{
  "policy_id": "prompt-injection-deny",
  "effect": "deny",
  "actions": ["prompt.submit"],
  "principal": {"type": "agent", "condition": {"equals": ["agent.tier", "untrusted"]}},
  "resource": {"type": "prompt"},
  "conditions": {
    "match": {
      "prompt.content": {
        "regex": "(?i)(system:|ignore previous|self-destruct)"
      }
    }
  }
}

Upload Cedar packs via the same import command with --engine cedar-json; FleetForge routes them to the policy microservice today and will embed the Cedar runtime into the Rust executor once perf benchmarks match Rego→Wasm.

Provenance for imported packs​

  1. Import the pack (fleetforge-ctl policy import ...).
  2. Inspect it (fleetforge-ctl policy inspect <PACK>), review the provenance JSON, and attach reviewer approvals.
  3. Commit the generated provenance file under policy-packs/provenance/<pack>.json so CI tracks drift.
  4. Optionally call fleetforge-ctl policy publish --scitt to anchor the provenance in the SCITT feed.
  5. Reference the provenance entry inside deployment manifests via policy.provenance_id so Control Plane logs prove which pack version executed.

Capability credentials roadmap​

  • Today: every step carries a scoped capability token enforced by the runtime (docs/concepts/policy.md#capability-credentials-roadmap).
  • Next: tokens project into Biscuit v2 credentials and W3C Verifiable Credentials, letting downstream systems validate scopes and provenance even offline.
  • Plan: exported policies reference the same provenance + capability chain so TrustOps and auditors can correlate “who allowed what” without calling the runtime.

Additional references​