Compliance Mapping

Edictum enforces runtime contracts 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 contract names a specific risk (e.g. `no-destructive-bash`, `no-secrets-in-args`).	YAML contract file listing all enforced risks. `edictum validate` confirms contracts are well-formed.
Risk estimation and evaluation	Observe mode (`mode: observe`) runs contracts in observe mode without denying, letting you measure how often each contract would fire on real traffic.	Audit events with `action: call_would_deny` record observed denials. Query `decision_name` to get per-contract frequency.
Risk mitigation	Enforce mode (`mode: enforce`) denies tool calls that violate contracts. 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 contract 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 contract 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	Contract 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 contract 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.denied` / `edictum.calls.allowed` counters on dashboards.
Human-in-the-loop observe mode testing	Observe mode evaluates contracts without enforcing them, producing `call_would_deny` audit events. Teams review observed denials before switching to enforce mode.	Pipeline configured with `mode: observe`. Audit log analysis showing observed denial 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.	Contracts 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-contract observe mode lets operators disable enforcement on individual contracts without a full redeploy. `edictum replay` lets operators preview the impact before re-enabling enforcement.	Per-contract `mode: observe` in YAML. `edictum replay <contracts.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 contracts 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 denies 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 `ToolEnvelope`, `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 contracts 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 contracts 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 contracts 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 contracts 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 audit trail	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 denied 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 contract or pipeline logic reads it automatically.	Session contracts 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 contract file. This ties every decision to a specific, reproducible contract state.	Audit events with `policy_version` field. Contract files stored in version control.
Change impact analysis	`edictum diff` compares two contract files and reports added, removed, and changed contract IDs. `edictum replay` re-evaluates historical audit events against a proposed contract 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 contract loading failure. The system fails closed (denies tool calls) when contracts cannot be loaded, and records the error state for monitoring.	Alerts on `policy_error: true` in audit events. Monitoring dashboard for contract load failures.
Staged rollout	Per-contract observe mode allows new contracts to be deployed in observe mode, evaluated against real traffic, and promoted to enforce mode after validation.	New contracts 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 contracts on the tool calls that result from a successful injection. A prompt injection that tricks an agent into calling `rm -rf /` is denied 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 contracts on destructive tools. Audit events with `decision_source: yaml_pre`.
LLM02:2025 Sensitive Information Disclosure	Partial. `deny_sensitive_reads()` denies access to `.env`, `.ssh/`, `.aws/credentials`, and key files. Sandbox contracts 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 `effect: redact` strip matched patterns (SSNs, API keys, credentials) from tool output before it reaches downstream consumers. `effect: deny` suppresses output entirely for READ/PURE tools. This covers tool output only -- LLM text output is not inspected.	Postcondition contracts with regex patterns. Audit events with `postconditions_passed: false`.
LLM06:2025 Excessive Agency	Strong. Session contracts cap per-tool, per-session, and per-attempt counts. `max_attempts` catches retry loops. Principal-based contracts enforce role-level permissions. Approval gates (`effect: approve`) 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 contracts. Preconditions with `effect: approve`. 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. Contract bundles are protected by SHA-256 hashing for change detection. Ed25519 signing is implemented on the console 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 contracts 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 deny unauthorized tool calls regardless of how the agent was manipulated. A hijacked goal that results in a tool call is evaluated against contracts -- the hijack's influence stops at the enforcement point.	Precondition contracts on all tools. Audit events with `action: CALL_DENIED`.
ASI02: Tool Misuse	Strong. Sandbox contracts restrict file paths (`within`/`not_within`), commands (`allows.commands`), and domains (`allows.domains`) to explicit allowlists. Tools operating outside boundaries are denied before execution.	Sandbox contracts in YAML. Audit events with `decision_source: yaml_sandbox`.
ASI03: Identity & Privilege Abuse	Strong. Principal-based contracts enforce role-level permissions on every tool call. Contracts can require specific `principal.role`, `principal.ticket_ref`, or `principal.claims` values.	YAML contracts with `principal.*` selectors. Audit events with full `principal` dict.
ASI05: Unexpected Code Execution	Strong. Preconditions deny dangerous shell patterns (`rm -rf`, `sudo`, `curl\|sh`). `BashClassifier` categorizes commands by side-effect level. Sandbox `allows.commands` restricts which commands can execute.	Precondition contracts 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 contracts.
ASI09: Human-Agent Trust Exploitation	Partial. Approval gates (`effect: approve`) require human sign-off for high-risk operations. Contracts can enforce boundaries on sub-agent spawning and cross-tool chaining. The audit trail provides evidence for post-hoc review. However, Edictum cannot prevent an agent from producing misleading explanations in text.	Preconditions with `effect: approve`. 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 contracts 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 contract 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 denial 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