04 / AI Explained · Field briefing
Agents need boundaries
A tool call changes the stakes.
An assistant that proposes a reply and an agent that sends it have different responsibilities. Tool access changes the consequence of a generated answer. The important design question is not whether a system is called an agent, but what it can read, change, trigger and spend.
When does an assistant become a system that can act?
An explanatory schematic—not a live system or measured performance.
KAF World Digital · Prepared 4 October 2026 · First editorial edition. Worked examples are invented for teaching.
Try the example02 / Where the gate belongs
Where the gate belongs
A typical agent loop selects an action, calls a tool, receives a result and decides what to do next. Some workflows use fixed steps instead. More autonomy is not inherently better: if the route is predictable, a conventional workflow may be easier to inspect and recover.
Take an invented support workflow. The agent can read a ticket and an approved policy, prepare a response and propose store credit. Reading, drafting and issuing credit should not be one undifferentiated permission. An approval screen should show the actual recipient, amount, reason and applicable policy before the credit tool runs.
Put consequential checks at the action boundary. A general instruction to “be careful” is not a substitute for a tool that enforces allowed recipients or maximum amounts. Likewise, an output check after a tool has run cannot undo a message already sent. Approval and validation need to occur before the side effect they control.
Permissions should be narrow enough to describe. Restrict directories, data scopes, destinations and budgets where the environment supports it. Cap retries and make uncertainty visible. A failed action may need an idempotency key or an explicit status check before retrying; repeating a request can otherwise create a duplicate.
External material can contain instructions that conflict with the user's goal. Treat web pages, documents and tool responses as untrusted inputs unless their authority is established. Prompt injection is a system-design problem involving permissions, tool boundaries and information flow, not something a single warning sentence reliably solves.
Keep a useful audit trail: what was proposed, which inputs informed it, who approved it, what actually executed and whether recovery succeeded. Review this with synthetic cases before using real accounts. Neither a sandbox nor a guardrail provides a universal safety guarantee.
Evidence for the technical mechanisms: OpenAI Agents SDK · Human-in-the-loop, OpenAI Agents SDK · Guardrails. The worked examples and practical framework are KAF editorial recommendations.
03 / Worked example
Step through the boundary
Understand the boundary between preparing an answer and taking an action. This interactive lesson uses prepared synthetic examples and local calculations.
Use the companion worksheet and the worked example. All assumptions are illustrative.
No account, model API or external service is connected. Inputs are not submitted or stored by this page.
04 / Go deeper
Useful words. Important details.
- Agent
- A system that can select actions and use tools as part of a workflow.
- Permission
- A capability granted and enforced by the system, not just requested in a prompt.
- Approval gate
- A decision point before the consequential action it controls.
- Idempotency
- A design property that avoids duplicate effects when the same operation is retried.
Approval is before execution
An output guardrail after execution cannot prevent an already-completed side effect. Place required authorisation and parameter checks at the tool boundary. Framework defaults and timing must be checked in the version deployed.
A retry needs state
Before retrying an uncertain operation, determine whether it executed. Idempotency keys and transaction records can help prevent duplicates; their behaviour is specific to the downstream system.
A sandbox limits a surface
Isolation, resource caps and network limits reduce the capabilities available to generated code. They do not make all inputs safe or guarantee that allowed actions serve the user’s intent.
The technical notes qualify the explanation; they are not product-specific assurance or a certification.
05 / Evidence & scope
Inspect the source.
Keep the context.
Sources were accessed on 4 October 2026. These technical and security references support the mechanisms described; they do not validate our fictional examples or establish comparative product performance.
- OpenAI Agents SDK · Human-in-the-loop
Approval before sensitive tool execution, paused runs and explicit decisions.
- OpenAI Agents SDK · Guardrails
Checks have different workflow boundaries; parallel checks may finish after side effects start.
- OWASP · Excessive Agency, 2026
Limit tools, functionality, permissions and autonomy; enforce authorisation outside the model.
- Hugging Face · Secure code execution
Code-execution risks and layered execution controls; no universal safety guarantee.
What this briefing does—and does not—establish
The worked examples, suggested questions and worksheets are original KAF teaching material. Numbers are explicitly illustrative. No customer data, observed adoption results, market-size forecast or live provider pricing is presented.
Check the exact product, release, configuration and policy before using a workflow. Source documents can change; this is a dated educational briefing.
Keep a useful copy.
Read the full briefing offline, or use the companion worksheet to apply it.