01 / Field notes
Executive Summary
An agent that can send messages, update records or launch jobs needs more than a well-worded prompt. Its execution path needs limits that remain effective when the model is confused, retries a request or encounters hostile content. Those limits should be inspectable without asking the model whether it behaved safely.
OWASP's agent-security guidance emphasizes bounded privileges and controls around agent behavior. [1] A practical implementation separates proposal from execution: the model describes an action, application code validates it, policy decides whether approval is required, and a controlled executor performs the permitted operation.
This guide develops that pattern for a fictional support assistant. It focuses on ordinary operational failures as well as malicious instructions, because a duplicate action can cause harm even when nobody is attacking the system.
02 / Field notes
Prerequisites / Lab Setup
Create a sandbox with invented support tickets and a mail sink that cannot deliver to real recipients. Give the assistant a small set of explicit tools: read a ticket, draft a response and request a status change. Keep administrator and production credentials out of the environment.
Define the unit of each limit. “Ten actions” is ambiguous if one action can target a thousand customers. Track objects affected, messages sent, total execution time and any relevant financial or resource budget. Decide which limits apply per request, user, tenant and rolling time window. State who can change them.
03 / Field notes
Technical Analysis
Put the policy outside the conversation
The tool interface should accept a constrained operation with validated parameters. A request to update a ticket must identify a permitted ticket and an allowed state transition. An unrestricted shell or arbitrary URL-fetch tool expands the boundary far beyond a support workflow and requires a different risk assessment.
In the fictional assistant, reading a ticket is automatic within the user's scope. Sending a response requires approval of the exact recipient and message. Closing multiple tickets requires a separate batch limit and preview. These are editorial design choices, not universal thresholds or guarantees.
| Control | What it constrains | Failure to test |
|---|---|---|
| Object scope | Which records the caller may affect | Valid user requests another tenant's ticket |
| Action budget | How much work can occur | A retry loop exceeds the allowed count |
| Approval binding | The exact proposed change | Recipient or body changes after approval |
| Idempotency | Repeated execution of one intended operation | Network timeout causes duplicate sending |
| Cancellation | Future and in-flight work | Queued jobs continue after stop |
Bind approval to a concrete operation
An approval screen should show what will happen, not merely ask whether the user trusts the agent. For a message, show the recipient and final content. For a record update, show the object, previous value and proposed value. Store an integrity-protected representation of the approved parameters and verify it before execution.
If the model revises the message after approval, the previous decision no longer covers the new content. Likewise, approval for one recipient should not authorize a later expanded recipient list. Define a short validity period where appropriate and ensure approvals cannot be replayed for unrelated operations.
Design retries before they happen
A timeout does not reveal whether a downstream service committed the action. Blindly repeating a send or update can duplicate it. Use the service's supported idempotency mechanism where available, or maintain an application operation record with a stable identifier and reconciled state. Do not invent a local “sent” flag that is written before the remote result is known and never checked again.
The fictional mail sink can simulate a response timeout after accepting a message. The correct result is one intended delivery and a clear operation state, not two messages or a permanently ambiguous success badge. Document how an operator resolves uncertainty when the downstream service lacks reliable deduplication support.
Make stop behavior observable
A stop button should change execution state that workers actually consult. Distinguish work not yet started, a request currently in flight and an action already committed. Cancellation may prevent the first, may or may not interrupt the second, and generally cannot undo the third without an explicit compensating operation.
Test a queue of harmless sandbox actions, stop midway and inspect the operation log. State which actions completed and which were canceled. Do not label the entire sequence “reversed” unless the application really performed and verified the relevant reversals.
As agents become more autonomous, the important improvement is accountable execution under uncertainty. More capable planning increases the need for precise limits; it does not make those limits obsolete.
04 / Field notes
Mitigation / Defense
- Start with the smallest tool set and narrowly scoped resource permissions.
- Enforce budgets in shared server-side state so parallel requests cannot bypass them.
- Bind required approvals to exact parameters and reject altered or expired approvals.
- Exercise duplicate delivery, timeouts, partial failure and cancellation in a sandbox.
- Keep audit records for decisions and results without logging secrets or unnecessary customer text.
Use MCP authorization for connection-level trust and RAG authorization for retrieved data. These controls compose with execution policy; none substitutes for the others.
05 / Field notes
References
Checked 28 October 2026. OWASP is the security reference; the support workflow, limits and fault-injection scenarios are illustrative engineering designs. No real customer actions or messages were executed. A finite set of acceptance tests reduces known failure modes without proving unrestricted autonomous behavior safe.
- AI Agent Security Cheat Sheet ↗OWASP · accessed 2026-10-28
Questions readers ask
Is an instruction telling the agent to ask first enough?
No. Enforce approval and limits in the execution layer. The model’s proposed plan is not authorization.
Does pressing stop reverse completed actions?
Usually not. Define cancellation for queued and in-flight work separately, and document compensating actions for changes already committed.
About this edition: Articles include AI-assisted drafting and editing. Conceptual illustrations are not evidence of a real incident or product test. Read our sourcing and review standards.
Research improves with scrutiny. Send a correction with the article URL and supporting evidence.
Contact the editorial desk ↗
