Runtime Governance

Edictum is runtime governance for production AI agents.

Agent frameworks build the agent. Edictum checks what the agent is about to do before the tool executes: allow, block, ask for approval, warn, redact, and record the decision.

Runtime Boundary Levels

A runtime policy starts by naming how much operational freedom the agent should have.

Level	What the agent can do	Runtime boundary
Read-only	Inspect approved context, summarize, search, or answer without changing state	Read-only tools, tight data scopes, low session limits, audit-only process evidence
Bounded action	Execute bounded work inside a declared workflow	Read/write tools inside sandbox boundaries, stage evidence, approvals for critical transitions
Broad action	Operate across broad systems with material side effects	Strong sandboxing, explicit approval points, terminal stages, stricter session limits, audit review

The demand center is bounded action: agents useful enough to do production work, but constrained enough that teams can review, approve, and audit what happened.

Data Operations

Runtime policies should also declare what kind of data operations the agent can perform.

Operation shape	Meaning	Typical Edictum boundary
Read-only	The agent can inspect approved data but cannot mutate systems	Rulesets allow read tools, block write tools, and sandbox paths, commands, or domains
Write-only	The agent can submit bounded writes without reading broad context	Workflow Gates require evidence from trusted inputs, rulesets restrict write targets and payload shape
Read/write	The agent can read context and then change state	Workflow Gates enforce read-before-write, rulesets limit both read scope and write scope

Read/write agents need the strongest process checks because the agent can use retrieved information to decide what to change. That is where Workflow Gates matter most.

From Policy To Runtime

A documented policy becomes executable when each claim maps to an enforcement point.

Policy claim	Runtime boundary
The agent may read only approved sources	Sandbox rules for paths, commands, domains, and data tools
The agent may write only within a scope	Pre-execution checks and sandbox boundaries for write tools
The agent must inspect evidence before changing state	Workflow Gate entry or exit conditions such as `file_read(...)` and `command_matches(...)`
A human must approve critical transitions	Workflow Gate `approval` blocks or `action: ask` rules
The behavior must be auditable	Audit events, workflow snapshots, and observed ruleset events

Edictum turns documented agent rules into executable runtime checks.

Rulesets And Workflow Gates

Rulesets and Workflow Gates enforce different parts of the same runtime policy.

Rulesets enforce single tool-call boundaries:

Is this tool allowed for this principal?
Is this file path, command, domain, query, or payload inside the declared boundary?
Has this session exceeded a tool-call or attempt limit?
Should this output warn, redact, or block?

Workflow Gates enforce ordered process with evidence:

Has the agent read the required source before writing?
Has the agent produced command evidence before advancing stages?
Has a human approved a critical transition?
Has the session reached a terminal stage where more action should stop?

Rulesets answer whether one call is in bounds. Workflow Gates answer whether the agent is allowed to be at this point in the process.

Behavioral Conformance

Edictum records runtime behavior against declared rules and workflow evidence.

Useful metrics include:

allowed vs blocked tool-call rate by ruleset version
observed would-block rate before switching a ruleset to enforce mode
stage completion rate by Workflow Gate
blocked stage advances caused by missing evidence
approval request, approval grant, and approval timeout rate
session attempt-to-execution ratio for retry loops
ruleset, workflow, principal, and adapter version tied to each audit event

These metrics show whether the agent stayed inside its runtime rules. They also show where the policy is too loose, too strict, or missing evidence.

What Edictum Does Not Measure

Edictum does not replace output-quality evals.

It does not measure:

accuracy
correctness
relevance
coherence
answer quality
task success
user satisfaction

Use Edictum for runtime enforcement and behavioral conformance. Use output-quality evals to judge the quality of what the model says or produces.

Example Policy

policy:
  name: support-refund-agent
  data_operations: read_write
  boundaries:
    reads:
      - customer_case
      - order_status
    writes:
      - refund_request
  required_process:
    - read_case_before_refund
    - evidence_before_stage_advance
    - approval_before_refund_over_250

The policy becomes executable through:

a ruleset that allows only approved read and write tools
sandbox rules that restrict data sources and mutation targets
a Workflow Gate that requires case evidence before refund creation
an approval boundary before high-value refunds
audit events that record every decision

On this page