Describe the authority you are delegating
Consider an assistant that reads customer requests and prepares refunds. Summarizing a request is relatively reversible; issuing money is not. List every action the agent can take, the systems it can reach, and the harm an incorrect action could cause. Distinguish reading records, drafting recommendations, modifying records, and executing financial transactions.
Set an initial boundary: the agent may retrieve authorized order details and draft a refund recommendation, but a human approves payment. This is a product constraint, not a prompt suggestion. OpenAI recommends human review where feasible, particularly in high-stakes uses, and adversarial testing of application behavior. [1](https://developers.openai.com/api/docs/guides/safety-best-practices)
Expose narrow tools with server-side rules
Avoid giving a general-purpose agent unrestricted database queries or a broad administrator credential. Provide a tool such as get_order_summary that returns only fields needed for the task. A refund tool should accept a specific order identifier, amount, currency, and reason, with authorization and business-rule checks implemented outside the model.
Validate input types, allowed values, order ownership, refund eligibility, and cumulative refunded amount on the server. Never assume a model-generated argument is trustworthy because it matches a JSON schema. Schema validation checks structure; it does not establish permission or business correctness. Use scoped credentials and separate read permissions from write permissions wherever the underlying systems support that distinction.
Treat external text as untrusted data
Customer messages, web pages, attachments, and retrieved records may contain instructions designed to redirect the agent. A message saying to ignore company policy and send a full customer export is not an authorized change request. Keep application instructions separate from external content, and avoid allowing retrieved text to select credentials, destinations, or permission scopes.
Test realistic attacks embedded in ordinary-looking content. Include a shipping note requesting a tool call, an attachment with fake administrator instructions, and a web page suggesting that secrets be copied into a diagnostic URL. Content filters can help, but they are not a substitute for restricting which actions the application will actually execute.
Make approval meaningful and replay-safe
For sensitive actions, show the reviewer the exact proposed change, relevant evidence, destination, and consequences. Approving a vague statement such as handle the refund is weaker than approving a particular amount for a particular order. Bind approval to the validated parameters and expire it if those parameters or the underlying order state change.
Design for retries. Use an idempotency key or equivalent transaction control so a network timeout does not turn one approved refund into two. Log the approval identifier and execution result. If the downstream service cannot provide safe retries, route uncertain outcomes to manual reconciliation instead of asking the agent to guess whether a payment succeeded.
Limit loops, spending, and disclosure
Set maximum tool calls, execution duration, token expenditure, and retry attempts per run. Add circuit breakers for repeated authorization failures or unexpected tool sequences. An agent stuck investigating a missing record should stop with a useful explanation rather than repeatedly calling expensive services.
Redact secrets and unnecessary personal information from traces. Keep enough information to reconstruct the action path, but apply access and retention controls to those logs. OpenAI describes traces as end-to-end records of model calls, tool calls, guardrails, and handoffs that can support workflow-level evaluation. [2](https://developers.openai.com/api/docs/guides/agent-evals) Operational visibility should not create a second uncontrolled copy of sensitive customer data.
Prove the boundaries with scenario tests
Build test cases covering ordinary requests, ambiguous requests, unauthorized users, malicious documents, duplicate submissions, stale approvals, and downstream failures. Score both task completion and policy compliance. A fast, apparently helpful agent that violates refund limits should fail the release test, even if the final customer-facing message sounds appropriate.
Begin in a sandbox or recommendation-only mode using synthetic records. Review traces, compare actual tool arguments with expected arguments, and verify that denied actions were truly blocked. Expand authority only after observing reliable behavior and retaining a rollback path. The goal is not to make the agent promise caution; it is to make unsafe actions difficult or impossible for the surrounding system.
Sources & further reading
Last editorial review: 27 October 2026. Examples are educational, not live employer data or guaranteed outcomes.