Enforcement matrix

Different agent frameworks expose tool execution at different boundaries. Some run the agentic loop in Python, where the SDK can sit between the model and the tool and physically prevent a dangerous dispatch. A couple run it in a subprocess or on managed infrastructure, where the SDK can record what happened but cannot intervene before it happens. This page is the honest, locked contract for what egisai can stop before it happens versus what it can only audit after the fact, framework by framework. This honesty matters for compliance. SOC 2, GDPR, HIPAA, and ISO 27001 auditors care that a control either fires preventively or is honestly labelled as detective; conflating the two erodes audit trust. Every audit row written by EgisAI carries an enforcement_status field that distinguishes the two states, and this page is where you discover, per framework, which state to expect.

​

Two enforcement seams

Two seams matter for compliance:

1. Tool / MCP call enforcement — block dangerous tool dispatches (deny_tool_call, deny_mcp_call, semantic_guard) before the tool runs.
2. Tool result enforcement — block or mask PII (pii_scan, deny_output_regex, semantic_guard) in the tool’s response before the model is shown it.

A row in the matrix below says enforced when the SDK can physically prevent the failure mode in question. It says advisory when the SDK observes after the fact and records the violation in the audit log but couldn’t intervene.

​

The matrix

​

What you can rely on

For every row above except Bedrock Agents:

• A deny_tool_call, deny_mcp_call, or semantic_guard verdict on a tool call physically stops the tool from running.
• A pii_scan, deny_output_regex, or semantic_guard verdict on a tool result either masks the result in place (action = "sanitize") or refuses it (action = "block") before the model is shown it. For Tier 1 and Tier 2 frameworks this happens on the next round trip’s input phase; for the Claude Agent SDK it happens at the PostToolUse hook so the model never sees the raw bytes for one turn.
• Input-side policies (pii_scan, deny_regex, allow_model, max_prompt_chars, semantic_guard on the prompt) always run before the model is called.
• Sanitization rewrites the prompt locally before it reaches the provider — the raw value never crosses the SDK boundary.
• Audit rows distinguish enforcement_status = "enforced" (the SDK actually prevented the action) from enforcement_status = "advisory" (the SDK observed after the fact). SOC 2 / GDPR auditors can query both states with a single SQL clause.

For Bedrock Agents specifically, see the SDK’s public SECURITY.md for the architectural limitation. The limitation is publicly documented so customers can risk-assess accordingly and pick a different framework for workflows that require pre-execution gating.

​

Aggregated OUTPUT replay (Claude Agent SDK)

For the Claude Agent SDK only, there is a third evaluation pass that runs on the aggregated assistant stream at ResultMessage. When that evaluation replays structured tool_calls that the CLI subprocess already executed, a verdict = "block" stamps enforcement_status = "advisory" on the enclosing model_call row — MCP / tool bytes were already replayed before Python aggregated them. Text-only violations still stamp enforced when hooks are wired. Applications using on_block = "raise" continue to see PermissionError in their code path; the audit flag distinguishes subprocess timing truth from caller withhold. The distinction is purely for SOC 2 / GDPR evidence — your code’s behavior is unchanged.

​

Why this is published

A governance product that quietly papers over its limits is worse than one that names them. The Bedrock Agents row above will fail every “what controls would have stopped this” question an auditor asks; we publish the matrix so a customer evaluating EgisAI for a Bedrock Agents workload knows up front to pick a different runtime for pre-execution gating, and so an auditor reviewing a Bedrock Agents audit row can see immediately that the advisory label is by design and not a regression. Every other framework on this list does physically prevent the failure modes listed above. If you ever see a tool call that ran despite a matching deny_tool_call policy on any framework except Bedrock Agents, or a tool result that reached the model despite a matching pii_scan or deny_output_regex policy on any framework except Bedrock Agents, that is a Critical-severity bypass and we want to know within hours — see the vulnerability disclosure section of the security page.

​

What’s next