Skip to main content
Use this guide when your application combines model calls with retrieval, tools, memory, or multi-step planning. The goal is to protect each boundary separately instead of hoping one prompt or one global policy covers the whole workflow.

Assumptions

  • You already know which user workflow the agent should support.
  • Your application, not the model, decides which tools exist and what each tool can do.
  • Anthale policies are available for the boundaries you want to evaluate.

Secure the workflow

1

Draw the workflow as boundaries

Write the exact points where untrusted content can change model behavior: user input, retrieved context, memory replay, tool output, model output, and tool execution.
2

Run Anthale before content crosses a boundary

Evaluate user input before the model call, retrieved context before prompt assembly, tool output before it is fed back into the model, and final model output before it reaches a user or another system.
3

Use different policies for different boundaries

Keep a narrower policy for retrieval or tool-output ingestion than for the final response path when the risks differ. Boundary-specific policies are easier to tune and explain than one catch-all policy.
4

Gate side effects outside the model

Treat tool execution as application logic, not model authority. Require allowlists, permission checks, and explicit approval for destructive or high-impact actions.
5

Preserve provenance in metadata and logs

Send metadata that tells you which boundary was evaluated, which feature invoked Anthale, and which tool or retrieval source was involved. That makes detect, redact, and block events operationally useful.
6

Test the workflow with indirect content

Try attacks that arrive through retrieved documents, tool output, summaries, and previous messages, not only through the first user prompt.
Anthale evaluates policy at the boundary. Your application still owns who can execute a tool, which resources that tool can touch, and whether a human needs to approve the action.

What this looks like in code

This pattern keeps Anthale at the user-input, retrieval-ingestion, and final-output boundaries. Tool execution still needs its own permission and approval controls in your application.

Common failure patterns

  • One policy is reused across every boundary even though the risks are different.
  • Retrieved or tool-generated text is appended to prompts without being evaluated first.
  • Model output is treated as an authorized command instead of a proposal that the application must validate.
  • Logs capture the Anthale action but not the boundary, source, or tool involved.

Apply this in Anthale

Next steps

Continue with Gate Tool Actions, Secure Retrieval Pipelines, Red-Team Agent Workflows, or Prompt Injection Protection.
Last modified on March 19, 2026