Policy

Policy is what the operator authors.

A configuration covering one or more agents (typically a pipeline). Inherits from organization defaults → project defaults → agent overrides.

One source of truth, ecosystem-agnostic: same Policy governs Claude Code, OpenShell, Monty, LangChain.

At a glance


Authored by	operators (via wizard + Compliance packs, or raw Rego in CI)
Inherits from	org defaults → project defaults → agent overrides (cascade, strictest-wins)
Two dimensions of content	Pipeline steps (the hot path) + Sandbox config (the runtime environment)
Three engines act on it	Policy engine, Policy compiler, Compliance packs

The two dimensions of Policy content

A Policy says both things at once. The same authoring surface produces both:

                         POLICY
                            │
            ┌───────────────┴────────────────┐
            ▼                                ▼
  Pipeline steps                    Sandbox config
  (the hot path)                    (the runtime environment)

  Run on every call,                Constrain the agent's environment
  in order:                         statically:

  • before-the-call                 • harness allow/deny
    (PII detect, cap-token check,   • OS sandbox (egress, FS)
     budget gate, …)                • interpreter (imports, memory)

  • during-the-call                 Applied at sandbox start
    (call the LLM / tool, signed    and re-applied on Policy change.
     mandate, audit-write)

  • after-the-call
    (output scan, redaction,
     trace finalization)

Both dimensions reach the agent, just through different paths:

The Policy engine (server-side, on the gateway path) executes the pipeline steps on every governed call.
The Policy compiler (server-side) produces a deployable Compiled Policy the host applies — that's what configures the harness, the OS sandbox, and the interpreter via Providers.

The three engines that act on Policy

These are sub-concepts of Policy, each with its own card:

Sub-element	What it does	Card
Policy engine	Runs the pipeline steps on every call (hot path). The 32-step engine in `tappass/gateway/`.	→ policy-engine
Policy compiler	Compiles authored Policy → signed Compiled Policy the host applies	→ policy-compiler
Compliance packs	Pre-built Policy starters (EU AI Act, OWASP LLM, …). Independent — Policy works without them; packs just save authoring time.	→ compliance-pack

Inheritance: org → project → agent

A Policy doesn't sit in isolation. It inherits:

Org defaults (CISO authors, applies to every agent in the org)
   │
   ▼ extended/strictened by
Project defaults (project lead authors, applies within one project)
   │
   ▼ extended/strictened by
Agent override (per-agent tweaks)

Cascade is strictest-wins: deeper levels can tighten, never loosen. An org-level "no PII to external endpoints" rule cannot be relaxed by a project; a project's deny Bash(curl:*) cannot be relaxed by an agent.

Authoring conveniences (optional)

Operators don't have to write Rego from scratch. Four authoring conveniences (defined fully in ../strategic/intent-to-policy, live on main) compose into Policy at increasing abstraction:

Authoring layer	What it captures	Example
Function	What is this agent for?	`refund_processor`, `customer_support_emailer`
Category	What kind of data?	`customer_pii`, `eu_residents`
Concern	What risks/regulations?	`data_leak`, `gdpr_required`, `pci_dss`
Capability	What can each tool do?	`external_messaging`, `pci_dss_scope`

These are authoring conveniences, not separate concepts. The intent-to-policy resolver (~40 LOC, shipped on main) collapses them into the same pipeline-step + sandbox-config dimensions described above.

Compliance packs are bundles of these conveniences pre-curated for specific regulations (EU AI Act, OWASP LLM Top 10).

Surfaces

Persona	Surface	What you do
Operator (terminal)	`tappass policy apply / list / show / diff / rollback`	author + manage
Operator (terminal)	`tappass policy apply --pack <name>`	apply a quick-start
Operator (visual)	Onboarding wizard	non-engineer authoring (categories + packs)
Operator (visual)	Dashboard policy editor	inspect with because-trail (which level / pack contributed each rule)
Auditor	Dashboard audit views	see which Policy authorized any given action

Why this matters

Without Policy as a concept, governance is ad hoc: each surface (settings.json on Claude Code, YAML on OpenShell, host-function spec on Monty) is configured separately, drifts independently, and no one source represents "what is this agent allowed to do?"

With Policy as the source of truth: one authoring surface, one inheritance tree, one provenance trail. Every per-target config is derived; nothing is hand-maintained.

Common confusions

Policy ≠ Pipeline steps. Pipeline steps are one of two dimensions of Policy (the hot-path arm). Policy also covers Sandbox config (the static-runtime arm). Both come from the same authored Policy.
Policy ≠ Compiled Policy. Policy is what the operator authors. Compiled Policy is the deployable, signed form of the same Policy — produced by the Policy compiler for one specific Sandbox.
Policy is ecosystem-agnostic. The same Policy governs Claude Code, OpenShell, Monty, LangChain. What differs per target is the Provider that translates the Compiled Policy into the target's native config format.
Compliance packs are accelerators, not separate Policy types. Policy works without them; packs are curated authoring shortcuts that produce the same kind of Policy you'd write manually.