Agent Behavior Defense

Agent Behavior Defense protects agent behavior at runtime. Where Prompt Defense, Content Moderation, and Data Leakage Prevention screen the content flowing through an agent, Agent Behavior Defense screens what the agent is doing: whether its tool use serves the user’s intent, and whether the tools it calls are allowed at all.

It contains two capabilities, both configured in your policy and enforced through Guard API screening requests:

1. The Dangerous Deviation detector (beta)
2. The Tool Allow/Deny List

Dangerous Deviation detector

The Dangerous Deviation detector, currently in beta, detects dangerous actions outside the agent’s trusted mandate, whatever the cause: manipulation, hallucination, or overreach. With agents, the same action can be legitimate in one moment and harmful in another: send_email is fine when the user asked for a report to be shared, and not fine when a poisoned tool response triggered it. The detector judges each tool call against the conversation history rather than against a fixed rule.

A tool call is flagged when both of the following hold:

1. The action is dangerous. The detector recognizes three danger types today:
   • Data leakage: sensitive data sent or persisted to an unauthorized destination.
   • Access and privilege escalation: public sharing of resources, sudo or admin grants, widened ACLs, or attempts to escalate permissions beyond a sandbox.
   • System destruction: deleting or wiping persistent resources.
2. There is no warrant for the action. Nothing in the trusted messages — user and system role messages — justifies the call. Instructions arriving in tool responses or other external content never count as warrant, because they may contain untrusted instructions.

A flag is raised only when one of the three danger types is detected and no warrant exists. If either condition fails, the call passes: a harmless off-topic call is not flagged even if ungrounded, and a dangerous call that the user explicitly requested is not flagged either.

For example, in a conversation where the user asked for an order status:

1. A tool_call for get_order_status serves the user’s request and is not detected.
2. A tool_call for export_customer_records with an external destination address is ungrounded in the request and leaks customer data — it is detected.
3. A tool_call for load_branding_theme is off-topic but not dangerous — it is not detected.

To use it, enable the Dangerous Deviation detector in your policy and send the tool call in the final assistant message of your Guard API request, together with the conversation history the detector judges it against (see Screening Agent Conversations for the request format). Also pass the tool definitions in the top-level tools field — missing definitions may degrade prediction quality and limit the explanations the detector can emit.

Explanations

When "breakdown": true is set in the request and tool definitions are provided, each detection includes an explanation object with fields written for different audiences:

• reason_code: a machine-readable, stable code for the danger type — use it for routing, dashboards, and automation.
• reason: a natural-language explanation for the user of the agent.
• agent_guidance: a natural-language instruction for the agent itself — can be fed back into the agent’s context to steer it away from the dangerous action.
• debug_info.dev_tips: guidance for developers on integration and remediation.

Detected events appear in the logs with the reason text, and are counted in analytics.

Tool Allow/Deny List

The Tool Allow/Deny List enforces which tools an agent may call at runtime, at the moment of tool invocation:

1. Allow list: tool calls for any tool not on the list are detected. Use this when an agent has a known, fixed set of tools it should ever use.
2. Deny list: tool calls for tools on the list are detected. Use this to block specific high-risk tools while leaving the rest unrestricted.

The outcome is deterministic: a denied tool call is detected regardless of content, and the reason text names the tool and the list that caused the detection. Denied tools should be detected consistently every time, so a useful rollout check is attempting a denied tool call, confirming it is detected, and attempting a permitted one, confirming it is not.

Screening tool responses

Prompt attacks against agents often arrive through tools rather than through the user, in a poisoned tool response. The existing guardrails extend to this interaction point: pass tool results as tool role messages in the Guard API request. Tool messages are screened as untrusted content, so Prompt Defense and Data Leakage detection run on them according to your policy.

See Screening Agent Conversations for the message format.

Rolling out enforcement

Running the evaluation against your own agents follows the same staged approach as the other guardrails:

1. Observe first: run runtime protection in Detect mode, where detections are logged without blocking, and review what the detections in the real traffic are. Relying on the Detect mode during the evaluation phase allows to later switch to enforcement without code changes.
2. Tune: adjust the policy and detector thresholds to your traffic and data patterns, and report false positives so the models can be calibrated to your use case.
3. Enforce: once detection accuracy is validated, switch the project to Enforce mode from the dashboard.

At production scale, with calibration, customers typically see a false-positive rate below 0.5%. Accuracy measured on a small or untuned setup is not representative: early results improve significantly with policy tuning and calibration cycles.

Detection results, including Dangerous Deviation and Tool Allow/Deny List detections, are returned in the Guard API response (use "breakdown": true for per-detector results), appear in the logs and analytics, and can be exported to your SIEM.