§ DOCUMENTATION

Runtime Guardrails

Per-agent tool-invocation policies, tool-output PII and injection scanning, and agent-to-agent credential authentication — enforcement that runs at call time, not just at policy definition time.

§ 01

The two runtime policy types

Execlave adds two new policy types that gate agent execution at runtime rather than at trace ingestion. Both are created via POST /api/v1/policies with the corresponding policyType value.

policyType	What it guards	When it runs
tool_invocation	Which tools an agent may call — allow/deny by tool name	Before the tool executes
tool_output_scan	The output a tool returns — scanned for PII and prompt injection	After the tool returns, before the agent sees it

Both types require the FF_RUNTIME_GUARDRAILS feature flag to be set in your backend environment. The flag defaults to off — existing behavior is fully preserved when it is absent.

§ 02

tool_invocation — allow/deny tool calls

A tool_invocation policy is a per-agent allow/deny list over which MCP tools the agent may call at runtime. Execlave evaluates the policy before the tool executes — if the tool is on the deny list or absent from the allow list (depending on your default action), the call is blocked and an audit event is recorded. No tool execution occurs.

curl -X POST https://api.execlave.com/api/v1/policies \  -H "Authorization: Bearer $EXECLAVE_API_KEY" \  -H "Content-Type: application/json" \  -d '{    "name": "Restrict data-exfil tools for research-agent",    "policyType": "tool_invocation",    "enforcementMode": "hard_block",    "ruleDefinition": {      "agentId": "agt_01j...",      "allow": ["web_search", "read_file"],      "deny":  ["send_email", "upload_file", "execute_code"]    }  }'

The ruleDefinition accepts an allow array, a deny array, and an optional agentId to scope the policy to a specific agent. Tools on the deny list are blocked unconditionally. Tools not listed on either array inherit the policy's default action.

§ 03

tool_output_scan — PII & injection screening

A tool_output_scan policy intercepts the value a tool returns before it flows back to the agent. Execlave delegates scanning to the processing service — the same detectors used by Injection Detection and PII Detection, via the /scan/pii and /scan/injection endpoints.

When PII is detected and pii_action is set to redact, the sensitive spans are replaced before the output reaches the agent. When injection is detected with enforcementMode: "hard_block", the output is suppressed entirely and a block audit event is recorded.

Scanning is latency-bounded. If the processing service is unavailable, Execlave logs a warning and passes the output through rather than halting the agent — a processing outage does not hard-block workloads.

curl -X POST https://api.execlave.com/api/v1/policies \  -H "Authorization: Bearer $EXECLAVE_API_KEY" \  -H "Content-Type: application/json" \  -d '{    "name": "Scan DB-query output for PII before agent sees it",    "policyType": "tool_output_scan",    "enforcementMode": "hard_block",    "ruleDefinition": {      "scan_pii": true,      "scan_injection": true,      "pii_action": "redact"    }  }'

§ 04

A2A credential authentication

When one agent calls another, Execlave can require the calling agent to present its verifiable credential before the downstream agent proceeds. This is controlled by the FF_A2A_AUTH feature flag (default off).

The credential used is the exe_agt_ credential issued via Agent Identity. On POST /api/v1/agents/authorize, Execlave verifies the caller's agent credential and records an a2a.authorize audit decision — granting or denying the inter-agent call with a full evidence trail.

A2A auth is additive: the calling agent still requires a valid API key or JWT for general API access. The exe_agt_ credential adds verifiable agent identity on top of that baseline.

§ 05

Enabling runtime guardrails

Both runtime guardrail capabilities are gated by backend environment flags. Set them in your backend .env or deployment configuration. When a flag is absent or set to false, the corresponding feature is inactive and prior behavior is preserved exactly.

Environment variable	Effect when true
FF_RUNTIME_GUARDRAILS	Activates tool_invocation and tool_output_scan policy types
FF_A2A_AUTH	Activates A2A credential verification on /api/v1/agents/authorize

The two flags are independent — you can enable tool-invocation and output-scanning without enabling A2A auth, and vice versa.

§ 06

Frequently asked questions

What happens when the processing service is unavailable during a tool-output scan?

Execlave fails safe. If the processing service (/scan/pii or /scan/injection) is unreachable, Execlave logs a warning and allows the tool output to continue to the agent rather than hard-blocking. This prevents a processing-service outage from halting agent workloads. The warning is recorded in the audit log so you can identify unchecked outputs during an incident review.

Can I allow some tools and deny others in the same tool_invocation policy?

Yes. The ruleDefinition for a tool_invocation policy accepts an allow list and a deny list. Tools on the deny list are blocked regardless of the allow list. Tools not appearing on either list inherit the default action defined in the policy — allow or deny based on your configuration. This lets you build a precise allowlist, a coarse denylist, or a combination of both.

Does A2A authentication replace regular API key auth for agent-to-agent calls?

No — A2A authentication is an additional layer on top of the existing credential system. When FF_A2A_AUTH is enabled, Execlave requires the calling agent to present its exe_agt_ credential (issued via Agent Identity) on the /api/v1/agents/authorize endpoint. The caller still needs a valid API key or JWT for general API access. A2A auth adds verifiable agent identity to the authorization decision and records an a2a.authorize audit event.

Are the FF_RUNTIME_GUARDRAILS and FF_A2A_AUTH flags independent?

Yes. FF_RUNTIME_GUARDRAILS controls tool_invocation and tool_output_scan policy types. FF_A2A_AUTH controls A2A credential authentication. You can enable either independently. Both default to off — when a flag is off, the corresponding behavior is not active and prior behavior is fully preserved. Set both to true in your backend environment to enable the full runtime guardrails suite.