Governance

Governance is the Trust-plane capability that decides what an agent can do, when, on whose authority, and what evidence the action must produce. It is enforced at a deterministic boundary — never delegated to model self-policing.

Definition

A coordinated set of: policy bundles (versioned JsonLogic rules scoped by intent and risk), guardrails (must_refuse, must_escalate, redaction_rules), native action-risk vectors, compatibility approval modes, approval gates (human checkpoints for high-risk steps), and an audit contract that ties every applied rule and gate decision back to a Decision Record.

Why it exists

Enterprise systems require enforceable controls. Models drift, prompts leak, tools misbehave. Governance makes the runtime safe under change by moving the decision boundary outside the agent — no model can talk its way around a deterministic policy check, an approval-mode tier, or an evidence requirement.

How it works

1. Policy bundles — versioned rules scoped by intent, risk, and channel.
2. Guardrails — must-refuse and must-escalate rules that override all other logic.
3. Action-risk vectors — new capabilities declare effect, authority, reversibility, interaction, and data scope independently.
4. Approval-mode compatibility — existing v1 capabilities retain a coarse mode while they migrate to the risk vector.
5. Approval gates — human authorization for high-risk steps with frozen evidence snapshot.
6. Enforcement — policies evaluated at compile, plan, and execute stages.
7. Audit — every applied rule, gate decision, and policy outcome is recorded against the run.

Action-risk vector (2026)

ApprovalMode is retained for v1 interoperability, but it is not a complete risk model and must not be treated as a universal total order. It combines unrelated properties: network describes an effect boundary, delegated describes authority, and destructive describes reversibility. New policy evaluates the native ActionRisk dimensions:

Each dimension is a policy input, not a score. A browser action does not become safe because it is reversible; a read does not become permitted merely because it has no write effect. The policy engine applies conjunctive constraints, then emits an effective vector and the legacy mode projection when a v1 consumer requires one.

Example: sending a calendar invitation through browser automation is { effect: external_state, authority: user_delegated, reversibility: compensatable, interaction: browser }. Deleting a local credential is { effect: local_state, authority: human_approved, reversibility: irreversible, interaction: computer }. The old tier ladder cannot represent that distinction safely.

Autonomy is a composite envelope, not a scalar

An agent is not simply “low” or “high” autonomy. Effective autonomy is the intersection of identity and delegation, permitted decisions, surfaced capabilities, resource and data scopes, amount and time limits, RunBudget, ActionRisk, evidence requirements, approval gates, and the current sandbox/network boundary. Policy evaluates these dimensions independently and denies when any required constraint is absent.

“Autonomy budget” is therefore useful shorthand for a policy composition, not a canonical runtime type or a pool of permission the model can spend. No favorable score on one dimension cancels a hard constraint on another. High confidence cannot buy broader authority; reversibility cannot authorize cross-tenant access; and remaining token budget cannot waive an approval.

Reversibility and recovery semantics

ActionRisk.reversibility classifies an effect as read_only, reversible, compensatable, or irreversible. For any non-read effect, policy should require an effect protocol that declares the observable postcondition, idempotency behavior, and one of rollback, retraction, compensation, or explicit non-recoverability. Execution records the resulting receipt and verifies external state independently of the agent’s success claim.

An “irreversibility budget” or standalone ReversalSpec can be explored as a future policy/schema extension, but neither is canonical today. Implementations must not use those terms to bypass ActionRisk, approval, postcondition, receipt, or recovery requirements.

Approval-mode tiers

Approval gates work better when bound to a shared vocabulary rather than to ad-hoc gate names per workflow. The five compatibility modes are retained for v1 contracts:

Wiring

• Tool capability declares approval_mode: destructive on the adapter contract.
• Policy can select a lower effective approval mode for a bounded request when the capability’s declared maximum allows it; it cannot exceed the declared maximum or invent a mode outside the taxonomy.
• The Decision Catalog records the effective mode and the approver identity per execution, enabling cross-workflow audit by risk class.
• New adapters also declare action_risk; during migration, policy validates that the legacy mode is a conservative projection of the vector.

Enforcement boundary versus approval path

ContextOS treats technical containment and authorization as independent controls:

The effective capability set is the intersection of the sandbox profile, identity scopes, active policy, and surfaced tool manifest. An approval may select a predeclared capability transition — for example, from workspace-only execution to one named network destination — but it must not silently replace the sandbox, mint broader credentials, disable a deny rule, or authorize an undeclared tool.

This separation prevents two common failures:

• A permissive sandbox is mistaken for business authorization.
• A valid approval is mistaken for unlimited technical capability.

Machine reviewers may classify an approval request, collect evidence, or recommend a verdict. They are approval authorities only when policy explicitly names an automated principal for that bounded class. Parse failures, reviewer failures, missing evidence, and timeouts fail closed. High-risk or irreversible classes still require the named human approver declared by policy.

Authority non-escalation

Untrusted information may influence reasoning but cannot grant itself authority. Prompt text, retrieved documents, memory records, tool metadata, tool results, web pages, extension manifests, and messages from peer agents are evidence inputs only. They cannot broaden the principal chain, delegation, capability set, destination, data scope, amount, time window, approval status, or risk ceiling.

Every transition recomputes effective authority as an intersection of the current identity claims, parent delegation, registered manifest ceiling, deterministic policy, technical containment, and any valid approval. Child agents, resumed sessions, recalled memory, and tool redirects inherit this non-escalation rule. A conflict or missing claim fails closed.

Policy outside agent code

Policy decisions never rely on model self-policing.

Boundary enforcement model

• Intercept every ToolCallEnvelope before adapter execution.
• Evaluate deterministic allow/deny decisions against current Run Context and claims.
• Refuse revoked agent registrations, expired or invalid identity claims, tenant mismatches, and child claims broader than the parent or manifest scope ceiling.
• Enforce parameter-level constraints (required fields, value limits, regex/pattern checks).
• Return structured denial obligations (escalate, request_approval, collect_evidence) to the Orchestrator.

Policy language and authoring

• Primary authoring surface: ContextOS policy DSL (JsonLogic-based in current runtime).
• Optional accelerator: NL-to-policy compilation for draft rules.
• Required safety checks for generated rules:
  • permissiveness drift (rule expands allowed surface unexpectedly),
  • restrictiveness drift (rule blocks critical safe paths),
  • unsatisfiable conditions (no runtime context can satisfy the rule).

Policy lifecycle

1. Author — create or update a policy bundle with versioned rules.
2. Validate — lint for unreachable rules, conflicts, and missing evidence.
3. Approve — security/governance review for high-risk domains.
4. Publish — promote to an environment-specific bundle version.
5. Enforce — apply at compile, plan, and execute stages.
6. Audit — record applied rules, evidence, and gate outcomes.

Runtime checkpoints

• Compile-time — policy selection + guardrail activation.
• Plan-time — verify steps and required evidence/approvals.
• Execution-time — just-in-time checks with latest context.

Audit expectations

• Emit a policy_decision_id and matched rule_ids[] for each boundary verdict.
• Persist input claims, normalized arguments, and decision rationale.
• Persist agent_identity.subject, agent_identity.claim_hash, principal_chain, kid, and scope summaries for each governed action.
• Tie every enforced policy outcome to the Decision Record for replay and compliance evidence.
• Approval-gate decisions persist the approver identity, frozen evidence snapshot hash, and the effective approval mode.

Regulatory timeline checkpoints (EU)

For teams operating in or serving the EU market, governance controls should map to:

• 2025-02-02: AI literacy obligations and prohibited-practice rules become applicable.
• 2025-08-02: General-purpose AI (GPAI) obligations apply.
• 2026-08-02: transparency obligations (including Article 50) broadly apply.

Operationally: policy bundles must encode transparency, disclosure, and human-oversight controls as runtime-enforced requirements, not post-hoc documentation tasks.

Implementation mapping

Governance is implemented primarily by:

• Policy Engine (rules, guardrails, approval gates)
• Decision Catalog (evidence requirements)
• Context Pack Compiler (runtime controls and redaction)

Implementation references

• Decision Catalog
• Context Pack
• High-Risk Workflow

Policy bundle structure (example)

{
  "bundle_id": "POLICY_RETURNS_V4",
  "effective_from": "2026-01-01",
  "priority": 10,
  "policy_dsl": {
    "language": "jsonlogic",
    "rules": [
      {
        "rule_id": "R_REFUND_REQUIRES_IDV",
        "applies_to": { "intent": "support.refund" },
        "if": { "==": [{ "var": "request.context.identity_verified" }, true] },
        "then": { "allow": true, "requires": ["order_lookup"] },
        "rationale": "Refunds require verified identity.",
        "citations": ["policy/returns_v4#sec2.1"]
      },
      {
      "rule_id": "R_HIGH_VALUE_REQUIRES_APPROVAL",
      "applies_to": { "intent": "support.refund" },
      "if": {
        "and": [
          { "==": [{ "var": "user.role" }, "support_agent"] },
            { ">": [{ "var": "request.context.refund_amount" }, 3000] }
          ]
        },
        "then": {
          "allow": true,
          "approval_mode": "destructive",
          "requires_approval_gate": "GATE_FINANCE_APPROVAL",
          "arg_constraints": { "refund_amount": { "max": 3000, "unless_approved": true } }
        },
        "decision_binding": "decision.support.refund.execute",
        "rationale": "High-value refunds require finance approval."
      }
    ]
  },
  "prohibited_claims": ["refund_guaranteed"]
}

Approval workflow (runtime)

1. Gate triggered — policy returns requires_approval_gate.
2. Context frozen — tool args + evidence snapshot stored.
3. Approver notified — role-based routing (e.g., fraud, finance).
4. Decision recorded — approve / deny with rationale.
5. Resume or halt — execution continues against the frozen evidence or is blocked.

Conflict resolution

• Priority wins — higher-priority bundles override lower ones.
• Guardrails first — must-refuse / must-escalate are absolute.
• Explicit deny beats allow — if two rules conflict, deny unless explicitly overridden by a higher-priority rule.

Interfaces

Inputs

• Policy DSL bundles and invariants
• Approval workflows and role definitions
• Risk classifications per intent or task
• Run Context (user, agent, tenant, claims)

Outputs

• Allow/deny decisions with reasons
• Required evidence references
• Effective approval mode
• Audit trails of policy application

Failure modes

• Policy drift across environments.
• Missing approval gates for high-risk actions.
• Evidence requirements not enforced at the right checkpoint.
• Overly strict policies causing deadlocks.
• Auto-generated rules with unsatisfiable conditions slipping past validation.

Operational concerns

• Policy version pinning per environment.
• Separation of duties for policy changes.
• Policy evaluation latency budgets.
• Approval queue SLAs by risk tier.
• Oversight allocation based on action risk and stratified coverage, never on the agent’s self-reported confidence alone.
• Recovery drills for reversible and compensatable effects; explicit executive acceptance for allowed irreversible classes.
• Policy rollback and deprecation windows.
• Regulatory control mapping to NIST AI RMF and ISO/IEC 42001 control families.

Evaluation metrics

• Policy compliance rate.
• Approval latency and rate by tier.
• Evidence attachment success rate.
• Audit gap rate (target: zero).
• Permission-violation rate.

Example

A VIP-instant-refund rule that selects a lower effective approval mode within the capability’s declared maximum:

{
  "rule_id": "R_VIP_INSTANT_REFUND",
  "applies_to": { "intent": "support.refund" },
  "if": {
    "and": [
      { "==": [{ "var": "intent" }, "support.refund"] },
      { "==": [{ "var": "request.context.user.is_vip" }, true] },
      { "<=": [{ "var": "request.context.refund_amount" }, 200] }
    ]
  },
  "then": {
    "allow": true,
    "approval_mode": "delegated",
    "requires_approval_gate": null
  },
  "decision_binding": "decision.support.refund.execute",
  "rationale": "VIP members get instant refunds up to limit; effective mode is delegated for this bounded request."
}

An identity- and supplier-bound execution example:

{
  "rule_id": "R_BOOKING_CANCEL_OWNERSHIP_AND_WINDOW",
  "applies_to": { "intent": "booking.cancel" },
  "if": {
    "and": [
      { "==": [{ "var": "request.context.booking.user_id" }, { "var": "user.user_id" }] },
      { "==": [{ "var": "request.context.supplier.cancel_window_open" }, true] }
    ]
  },
  "then": {
    "allow": true,
    "approval_mode": "delegated",
    "requires": ["supplier_policy_ref", "booking_ownership_proof"]
  },
  "else": { "allow": false, "reason": "supplier_window_or_identity_failed" },
  "decision_binding": "decision.booking.cancel.eligibility"
}

Common misconceptions

• Governance is not just logging. It is active enforcement at runtime with evidence-bound audit.
• Approval gates are not a bottleneck when scoped by risk. Most calls are read_only or local_write and never see a gate.
• Policy is not the model’s responsibility. The model proposes; the boundary decides.
• Approval modes are not interchangeable with gate names. Modes are compatibility classifications; gate names are runtime artifacts selected by policy.
• Approval modes are not a total risk order. Native policy evaluates the ActionRisk dimensions; the v1 mode is a compatibility projection.