On this page
Define the task before choosing a guardrail
An internal drafting assistant, a public chatbot, and an agent that changes business records need different controls. State what the feature may read, what it may produce, and what it may cause other systems to do. Record exclusions as clearly as capabilities.
In the AI shield architecture playbook, an assistant retrieves authorized company documents and drafts an answer. It cannot send that answer or change permissions. This narrow starting point makes the surrounding policy easier to test. Adding a new tool later is a change to authority, not merely a new prompt feature.
Put policy around the complete pipeline
Trace identity, retrieval, context assembly, model calls, output handling, caches, and telemetry. A control at the initial prompt boundary does not describe what happens in the rest of that pipeline. Keep provenance attached to source material as it is transformed and summarized.
Choose enforcement points that have the required context. Retrieval authorization belongs before private documents enter the model context. Output rendering belongs at the next consumer. Resource controls belong wherever work can be admitted or multiplied. The quickstart guide provides a review sequence for drawing these transitions with your team.
Keep deterministic authority outside the model
Use application rules for permissions, approved destinations, model allowlists, and task budgets. A classifier can contribute an uncertain signal, but a favorable score should not grant access that the caller otherwise lacks. Define how conflicting signals affect the outcome and who owns that policy.
For a high-impact action, the execution service should independently verify the operation and any required approval. For a read-only task, avoid exposing write tools at all. The LLM API shield section connects these authority boundaries to prompt injection, tool requests, and generated responses.
Minimize context and bound consumption
Select the smallest authorized context that supports the task. Keep provider credentials and unnecessary private fields out of prompts, caches, and routine logs. Test redaction against the intended task so that removing data does not silently produce a misleading result.
Budget the whole workflow rather than only the first request. Include generated tokens, retrieval depth, retries, tool steps, concurrency, and elapsed time where relevant. The rate limits and AI budgets guide explains how to connect admission, reservations, execution, and reconciliation while keeping estimates distinct from actual consumption.
Evaluate legitimate work and failure behavior
Build tests around full tasks, including cases that should succeed. Add unauthorized sources, oversized inputs, stale permissions, dependency outages, and exhausted budgets. Record the model, prompt, policy, retrieval configuration, and expected outcome for each case.
Decide degraded behavior before an outage. An unavailable permission check should not trigger an unfiltered fallback. A less critical quality check may support a restricted result instead. Retest relevant boundaries after changes to providers, prompts, tools, or data sources, and keep accepted residual risks attached to the feature’s decision record.
