Compliance Mapping

Edictum enforces runtime rulesets on AI agent tool calls. This page maps Edictum capabilities to specific requirements in the EU AI Act, SOC 2 Trust Services Criteria, the OWASP Top 10 for LLM Applications (2025), and the OWASP Top 10 for Agentic Applications (2026), with concrete configuration guidance for each control.

Capability mappings, not compliance attestations. The tables below show how Edictum features map to regulatory and framework requirements. Having a feature that maps to a control is not the same as passing an audit -- your organization must implement the processes, collect the evidence, and undergo independent assessment. Edictum provides the enforcement and audit tooling; your compliance program provides the governance around it.

EU AI Act

Article 9 -- Risk Management System

Article 9 requires providers of high-risk AI systems to establish a risk management system that identifies risks, estimates their likelihood and severity, adopts mitigation measures, and documents the process throughout the system lifecycle.

Requirement	Edictum Feature	Evidence / Configuration
Risk identification	Preconditions define what constitutes a risky tool call. Each rule names a specific risk (e.g. `no-destructive-bash`, `no-secrets-in-args`).	YAML rule file listing all enforced risks. `edictum validate` confirms rulesets are well-formed.
Risk estimation and evaluation	Observe mode (`mode: observe`) runs rulesets in observe mode without blocking, letting you measure how often each rule would fire on real traffic.	Audit events with `action: call_would_deny` record observed blocks. Query `decision_name` to get per-rule frequency.
Risk mitigation	Enforce mode (`mode: enforce`) blocks tool calls that violate rulesets. Side-effect classification (`pure`, `read`, `write`, `irreversible`) scales the response to the severity of the action.	Audit events with `action: call_denied` confirm active mitigation. `side_effect` field in each event shows the risk tier.
Documentation throughout lifecycle	`policy_version` (SHA-256 of YAML) tracks which rule set was active for every decision. `edictum diff` shows changes between versions. `edictum replay` quantifies the impact of proposed changes.	Audit log with `policy_version` field. CI pipeline running `edictum diff` on every rule change PR.
Residual risk monitoring	Postconditions run after tool execution and record warnings when results violate expectations. Failures are recorded on the `CALL_EXECUTED` event.	Audit events with `action: call_executed` and `postconditions_passed: false`.

Article 14 -- Human Oversight

Article 14 requires that high-risk AI systems are designed to be effectively overseen by natural persons, including the ability to understand the system's capacities and limitations, to monitor operation, and to intervene or interrupt.

Requirement	Edictum Feature	Evidence / Configuration
Understand capacities and limitations	Rule files are human-readable YAML that declare exactly what the agent is and is not allowed to do. `edictum check` lets a human test any hypothetical tool call without running it.	YAML rule file reviewed in code review. `edictum check` output in documentation or runbooks.
Monitor operation	Audit sinks stream every pipeline decision to local logs. OpenTelemetry spans route decisions to any observability backend (Datadog, Splunk, Grafana, Jaeger) via an OTel Collector.	`StdoutAuditSink` or `FileAuditSink` for local logs. `configure_otel()` or YAML `observability.otel` block for OTel span emission. OTel `edictum.calls.blocked` / `edictum.calls.allowed` counters on dashboards.
Human-in-the-loop observe mode testing	Observe mode evaluates rulesets without enforcing them, producing `call_would_deny` audit events. Teams review observed blocks before switching to enforce mode.	Pipeline configured with `mode: observe`. Audit log analysis showing observed block rates over time before cutover.
Intervene and interrupt	Principal-based gating allows human-specified context (role, ticket reference) to gate tool access. Session limits (`max_attempts`, `max_tool_calls`) automatically halt runaway agents.	Rulesets with `principal.role` conditions. `OperationLimits` configured with appropriate caps. Audit events showing `decision_source: attempt_limit` or `decision_source: operation_limit`.
Ability to override or reverse	Per-rule observe mode lets operators disable enforcement on individual rulesets without a full redeploy. `edictum replay` lets operators preview the impact before re-enabling enforcement.	Per-rule `mode: observe` in YAML. `edictum replay <rules.yaml> --audit-log <events.jsonl>` output in change management ticket.

SOC 2 Trust Services Criteria (CC6)

CC6.1 -- Logical Access Security

The entity implements logical access security software, infrastructure, and architectures to protect information assets.

Requirement	Edictum Feature	Evidence / Configuration
Logical access controls over AI agent actions	`Principal` object carries identity context (`user_id`, `service_id`, `org_id`, `role`, `ticket_ref`, `claims`) through the entire pipeline. Preconditions can gate tool access based on any principal field.	YAML rulesets with selectors like `principal.role: { in: [admin, sre] }` and `principal.claims.team: { equals: platform }`. Programmatic preconditions can also access `envelope.principal.role` in Python. Audit events containing the full `principal` dict.
Protection of sensitive data	`deny_sensitive_reads()` built-in blocks access to common secret paths (`~/.ssh/`, `.env`, `/var/run/secrets/`, AWS credentials). `RedactionPolicy` scrubs sensitive data from audit payloads.	`deny_sensitive_reads()` registered in Edictum. `RedactionPolicy` configured on all audit sinks.
Classification of information assets	`SideEffect` classification (`pure`, `read`, `write`, `irreversible`) categorizes every tool call by its potential impact. Unregistered tools default to `irreversible` (most restrictive).	`ToolRegistry` configuration with explicit side-effect assignments. Default `IRREVERSIBLE` for unknown tools.

CC6.2 -- Prior to Issuing System Credentials and Granting System Access

The entity authorizes, establishes, and manages credentials for system users.

Requirement	Edictum Feature	Evidence / Configuration
Identity propagation	`Principal` is set at the adapter level and propagated to every `ToolCall`, `AuditEvent`, and pipeline decision. All eight adapters support principal injection.	Adapter configuration passing `Principal(user_id=..., service_id=..., org_id=...)`. Audit events with `principal` field populated.
Credential-based access decisions	Preconditions can require specific principal fields to be present or match expected values before allowing tool execution.	YAML rulesets with `principal.user_id: { exists: true }`, `principal.role: { equals: admin }`, `principal.ticket_ref: { exists: true }`. Programmatic preconditions can check `envelope.principal` directly in Python code.

CC6.3 -- Authorization of System Access

The entity authorizes access to system resources consistent with job responsibilities.

Requirement	Edictum Feature	Evidence / Configuration
Role-based tool access	Preconditions gate tool access by `principal.role`. Different roles can have different tool permissions.	YAML rulesets with conditions like `principal.role in ["admin", "sre"]` for destructive operations.
Ticket-based authorization	`principal.ticket_ref` enables change-management workflows where destructive operations require an associated incident or change ticket.	YAML rulesets with `principal.ticket_ref: { exists: true }` for write/irreversible tools.
Claims-based fine-grained access	`principal.claims` is an extensible dict that carries arbitrary authorization context (e.g. team membership, feature flags, ABAC attributes).	YAML rulesets with `principal.claims.team: { equals: platform }` or similar custom claims selectors.

CC6.6 -- System Operations

The entity implements logical access security measures to protect against threats from sources outside its system boundaries.

Requirement	Edictum Feature	Evidence / Configuration
Comprehensive decision log	Every pipeline decision produces an `AuditEvent` with 27 fields covering identity, tool details, principal, decision rationale, execution outcome, and session counters.	Audit sinks configured and emitting. JSONL files or log aggregator queries showing complete event records.
Session boundary enforcement	`OperationLimits` caps total attempts (`max_attempts`), total executions (`max_tool_calls`), and per-tool executions (`max_calls_per_tool`).	`OperationLimits(max_attempts=500, max_tool_calls=200, max_calls_per_tool={"Bash": 50})`. Audit events with `decision_source: operation_limit`.
Runaway agent detection	`max_attempts` counts blocked calls too, catching agents stuck in retry loops. The `Session` object also exposes `consecutive_failures()` as a building block for custom hooks -- it tracks consecutive failed tool executions and resets on success, but no built-in rule or pipeline logic reads it automatically.	Session rulesets with `max_attempts`. Custom hooks can call `await session.consecutive_failures()` to implement circuit-breaker logic. Audit events with `session_attempt_count` and `session_execution_count`.

CC6.8 -- Change Management

The entity authorizes, designs, develops, configures, documents, tests, approves, and implements changes to infrastructure and software.

Requirement	Edictum Feature	Evidence / Configuration
Policy versioning	`policy_version` in every audit event is the SHA-256 hash of the YAML rule file. This ties every decision to a specific, reproducible rule state.	Audit events with `policy_version` field. Rule files stored in version control.
Change impact analysis	`edictum diff` compares two rule files and reports added, removed, and changed rule IDs. `edictum replay` re-evaluates historical audit events against a proposed rule file and reports what would change.	`edictum diff old.yaml new.yaml` in CI on every PR. `edictum replay new.yaml --audit-log prod.jsonl` in change approval workflow.
Policy error detection	`policy_error: true` in audit events indicates a rule loading failure. The system fails closed (blocks tool calls) when rulesets cannot be loaded, and records the error state for monitoring.	Alerts on `policy_error: true` in audit events. Monitoring dashboard for rule load failures.
Staged rollout	Per-rule observe mode allows new rulesets to be deployed in observe mode, evaluated against real traffic, and promoted to enforce mode after validation.	New rulesets added with `mode: observe`. Observe-mode audit events analyzed. Mode changed to `enforce` after review.

OWASP Top 10 for LLM Applications (2025)

The OWASP Top 10 for LLM Applications v2025 identifies the most critical security risks in LLM-powered systems. Edictum operates at the tool-call layer and addresses a subset of these risks. The table below maps each risk to what Edictum can and cannot do.

OWASP Risk	Edictum Coverage	Evidence / Configuration
LLM01:2025 Prompt Injection	Partial. Edictum does not filter prompts or detect injection attempts. However, it enforces rulesets on the tool calls that result from a successful injection. A prompt injection that tricks an agent into calling `rm -rf /` is blocked by preconditions -- the injection's influence stops at the enforcement point. This does not prevent text-only attacks that never trigger a tool call.	Precondition rulesets on destructive tools. Audit events with `decision_source: yaml_pre`.
LLM02:2025 Sensitive Information Disclosure	Partial. `deny_sensitive_reads()` blocks access to `.env`, `.ssh/`, `.aws/credentials`, and key files. Sandbox rulesets restrict file paths to explicit allowlists. Postcondition redaction catches secrets that appear in tool output. This covers disclosure via tool calls but not disclosure embedded in LLM text responses.	`deny_sensitive_reads()` precondition. Sandbox `within`/`not_within` boundaries. `RedactionPolicy` on audit sinks.
LLM05:2025 Improper Output Handling	Partial. Postconditions with `action: redact` strip matched patterns (SSNs, API keys, credentials) from tool output before it reaches downstream consumers. `action: block` suppresses output entirely for READ/PURE tools. This covers tool output only -- LLM text output is not inspected.	Postcondition rulesets with regex patterns. Audit events with `postconditions_passed: false`.
LLM06:2025 Excessive Agency	Strong. Session rulesets cap per-tool, per-session, and per-attempt counts. `max_attempts` catches retry loops. Principal-based rulesets enforce role-level permissions. Approval gates (`action: ask`) require human sign-off for high-risk operations. Every tool call passes through the full pipeline regardless of which tool triggered it. Unregistered tools default to `IRREVERSIBLE` (most restrictive).	`OperationLimits` configuration. Session rulesets. Preconditions with `action: ask`. Tool registry with explicit side-effect assignments.
LLM10:2025 Unbounded Consumption	Partial. Session limits (`max_attempts`, `max_tool_calls`, `max_calls_per_tool`) cap tool-call volume per session. The pipeline short-circuits on the first failure. This limits tool-call consumption but does not control token usage, API costs, or compute resources at the model layer.	`OperationLimits` in Edictum constructor or YAML `limits` block. Audit events with `decision_source: attempt_limit` or `decision_source: operation_limit`.

Risks outside Edictum's enforcement boundary

These risks operate at layers that Edictum does not cover (model training, supply chain, embeddings, text generation):

LLM03:2025 Supply Chain -- Edictum does not inspect third-party components, model weights, or training pipelines.
LLM04:2025 Data and Model Poisoning -- Edictum does not validate training data or model integrity. Ruleset YAML is protected by SHA-256 hashing for change detection. Ed25519 signing is implemented on the control-plane server side; SDK-side signature verification is planned but not yet shipped (see roadmap).
LLM07:2025 System Prompt Leakage -- Edictum does not filter LLM text output. If the system prompt leaks via text (not via a tool call), Edictum has no enforcement point.
LLM08:2025 Vector and Embedding Weaknesses -- Edictum does not inspect vector stores, embeddings, or retrieval pipelines.
LLM09:2025 Misinformation -- Edictum enforces rulesets on actions, not on factual accuracy of text responses.

See Defense Scope for a full analysis of what Edictum covers and where other controls are needed.

OWASP Top 10 for Agentic Applications (2026)

The OWASP Top 10 for Agentic Applications focuses specifically on autonomous AI agent systems. This list is more directly relevant to Edictum than the LLM Applications list above, because Edictum operates at the agent tool-call layer.

OWASP Risk	Edictum Coverage	Evidence / Configuration
ASI01: Agent Goal Hijack	Strong. Preconditions block unauthorized tool calls regardless of how the agent was manipulated. A hijacked goal that results in a tool call is evaluated against rulesets -- the hijack's influence stops at the enforcement point.	Precondition rulesets on all tools. Audit events with `action: CALL_DENIED`.
ASI02: Tool Misuse	Strong. Sandbox rulesets restrict file paths (`within`/`not_within`), commands (`allows.commands`), and domains (`allows.domains`) to explicit allowlists. Tools operating outside boundaries are blocked before execution.	Sandbox rulesets in YAML. Audit events with `decision_source: yaml_sandbox`.
ASI03: Identity & Privilege Abuse	Strong. Principal-based rulesets enforce role-level permissions on every tool call. Rulesets can require specific `principal.role`, `principal.ticket_ref`, or `principal.claims` values.	YAML rulesets with `principal.*` selectors. Audit events with full `principal` dict.
ASI05: Unexpected Code Execution	Strong. Preconditions block dangerous shell patterns (`rm -rf`, `sudo`, `curl\|sh`). `BashClassifier` categorizes commands by side-effect level. Sandbox `allows.commands` restricts which commands can execute.	Precondition rulesets on bash/shell tools. Sandbox command allowlists.
ASI06: Memory & Context Poisoning	Partial. Session limits (`max_tool_calls`, `max_attempts`, `max_calls_per_tool`) cap tool-call volume, preventing unbounded context manipulation through excessive tool use. This does not protect against poisoning of the LLM's context window via text.	`OperationLimits` configuration. Session rulesets.
ASI09: Human-Agent Trust Exploitation	Partial. Approval gates (`action: ask`) require human sign-off for high-risk operations. Rulesets can enforce boundaries on sub-agent spawning and cross-tool chaining. The decision log provides evidence for post-hoc review. However, Edictum cannot prevent an agent from producing misleading explanations in text.	Preconditions with `action: ask`. Audit trail with full tool-call details.

Risks outside Edictum's enforcement boundary

ASI04: Agentic Supply Chain Vulnerabilities -- Edictum does not inspect MCP servers, A2A protocols, or dynamically loaded agent components.
ASI07: Insecure Inter-Agent Communication -- Edictum does not authenticate or verify messages between agents. It evaluates tool calls from within a single agent process.
ASI08: Cascading Failures -- Edictum can limit individual agent tool-call volume (session limits), but does not coordinate across multi-agent pipelines to prevent cascading effects.
ASI10: Rogue Agents -- Edictum enforces rulesets on tool calls but cannot detect agent misalignment, concealment, or self-directed behavior that does not manifest as a tool call.

Audit Evidence Matrix

For auditors who need a quick reference mapping evidence artifacts to controls:

Evidence Artifact	EU AI Act	SOC 2
YAML rule file in version control	Art. 9 (documentation)	CC6.8 (change management)
`edictum validate` output in CI	Art. 9 (risk identification)	CC6.8 (testing)
`edictum diff` output in PR review	Art. 9 (lifecycle documentation)	CC6.8 (change impact)
`edictum replay` report	Art. 9 (risk estimation), Art. 14 (override preview)	CC6.8 (change impact analysis)
Audit events with `action: call_denied`	Art. 9 (risk mitigation)	CC6.6 (system operations)
Audit events with `action: call_would_deny`	Art. 14 (observe mode testing)	CC6.8 (staged rollout)
Audit events with `principal` populated	Art. 14 (oversight)	CC6.1 (logical access), CC6.2 (credentials)
Audit events with `policy_version`	Art. 9 (documentation)	CC6.8 (versioning)
Audit events with `policy_error: true`	Art. 9 (residual risk)	CC6.8 (error detection)
OTel dashboards with block rates	Art. 14 (monitoring)	CC6.6 (system operations)
`RedactionPolicy` configuration	--	CC6.1 (data protection)
`OperationLimits` configuration	Art. 14 (interrupt capability)	CC6.6 (boundary enforcement)

On this page