VIII · Safety & ControlEmerging★

Policy-Gated Agent Action (KRITIS)

also known as WORM-Tagged Agent Action, NIS2/EU AI Act Policy Gate

Each agent action passes through a policy gate (NIS2, EU the agent Act, BSI rules) and is tagged with Run ID + Model Digest + Policy Hash for WORM-audit reconstruction.

This pattern helps complete certain larger patterns —

  • specialisesPolicy-as-Code Gate★— Evaluate every proposed agent action against externally-managed machine-readable policies before dispatch, so compliance authorship lives outside the prompt and outside the agent code.

Context

An agent operates in regulated critical infrastructure (KRITIS): utilities, healthcare, finance, telecom. Regulators require provable per-action policy compliance and incident reconstruction. Free-running agents in such environments are inadmissible.

Problem

Without per-action policy gating and immutable audit trails, the operator cannot demonstrate to regulators that any specific agent action complied with the applicable policies at the time it executed. After an incident, the operator cannot reconstruct which model version, which policy rules, and which inputs produced the action. Differs from existing policy-as-code-gate by adding the WORM-tagging contract for incident reconstruction.

Forces

  • Agentic flexibility is the value proposition; gating every action adds friction.
  • Regulators require reconstruction over time horizons (years) longer than typical agent run logs.
  • Model versions and policy rules drift; an audit at year 3 must reflect the state at year 1.

Example

A grid-management agent proposes 'scale generation +50MW on bus 12'. Gate checks against NIS2 + national grid code + operator policy. Rule R-217 requires human confirmation when delta >30MW. Gate returns {accept: false, reason: R-217, requires: human}. WORM record written: {run_id, model: claude-opus-4-7@sha256:..., policy: 2026-Q2-grid@sha256:..., inputs_hash, decision: human-required}. Three years later an auditor reconstructs the exact policy version that governed the decision.

Diagram

Solution

Therefore:

Implement a policy-gate service that takes (proposed action, inputs, agent context) and returns {accept/reject, policy hash, rule citations}. Every accepted action carries a WORM-store record: Run ID, Model Digest (which LLM version), Policy Hash (which rule set), Inputs Hash, Decision. The store is append-only with cryptographic chaining (Merkle tree or similar). Pair with policy-as-code-gate, supervisor-plus-gate, decision-log.

What this pattern forbids. No agent action commits without a gate-decision record in the WORM store; the policy gate is on the critical path of every action.

And the patterns that stand alongside it, or against it —

  • complementsSupervisor-Plus-Gate★— Supervisor controller that validates and gates LLM outputs against deterministic checks before they commit to side-effects.
  • complementsDecision Log★★— Persist the agent's reasoning trace alongside its actions so post-hoc review can explain why.
  • complementsProvenance Ledger★★— Log every agent decision and state change with enough metadata to explain or reverse it later.
  • complementsApproval Queue★★— Queue agent-proposed actions for asynchronous human review while the agent continues other work.
  • complementsBPMN/DMN Deterministic Shell Around Agent★— BPMN processes and DMN decision tables form the deterministic spine; LLM-driven agents are invoked only at explicit 'unstructured problem' nodes inside the process.
  • complementsSynchronous Execution-Plan Confirmation★— Agent synchronously emits its full execution plan for user confirmation before any side-effect step, and provides asynchronous operation recordings for post-hoc review.
  • complementsPipeline Triad Pattern★— Staff each pipeline stage with a triad — Creator generates an artifact, Critic finds flaws, Arbiter makes a binding PASS/FAIL/PARTIAL decision — with four explicit human gates between stages.
  • complementsDecision Context Maps★— Before any consequential decision, require the agent to gather a declared set of contextual inputs (resource availability, schedules, downstream dependencies) into a 'context map' the decision must cite.
  • complementsContext Gap (Security)✕— Agents faithfully follow explicit security rules but miss the broader implications — they log access correctly without flagging the unusual pattern a human expert would catch immediately.
  • complementsProgressive Tool Access★— Grant tool permissions on a need-to-use basis, starting minimum and expanding only as the agent proves competency, mirroring how humans earn system access.
  • complementsDelegated Agent Authorization★— Have an agent act for a principal using scoped, short-lived, revocable delegated credentials rather than the principal's own static secrets, so each action stays attributable across the principal-to-agent-to-subagent chain and a compromise is contained.

Neighbourhood

Click any neighbour to follow the language. Scroll to zoom, drag to pan.

References

Provenance