Give AI a task. Keep the controls.

A chatbot generates an answer. An agent can choose a next step, call a tool, inspect the result and continue towards a goal. That loop can reduce manual coordination, but it also gives an unreliable component a path to real-world consequences.

1. Know what the loop actually does

A typical agent receives a goal and relevant state, proposes a tool call, receives the tool's response and decides whether to continue. Application code executes the call; the model should never be the authority that grants itself access. The loop needs explicit stopping conditions, such as a completed task, an uncertainty threshold, a time limit or a maximum number of steps.

Consider a support assistant investigating a delayed shipment. It may read the ticket, retrieve an order, check tracking and draft a response. Those are useful agent steps because the next action depends on what it finds. Issuing a refund is a different risk class and should require a separate policy check and, where appropriate, a person's approval.

A fixed workflow is often better when the sequence is known in advance. “When a form arrives, validate it and create a record” does not need autonomous planning. Use an agent where branching judgement adds value, not merely because the platform offers one.

2. Make permissions smaller than ambition

Define allowed actions before choosing a framework. Separate read-only tools from tools that modify records, send messages or spend money. Give each tool a narrow schema and enforce account scope server-side. A model-supplied customer ID must not bypass the signed-in user's permissions.

• Read: retrieve approved records with existing access controls.
• Draft: prepare an action that a person can inspect.
• Execute: perform a narrowly authorised, logged change.
• Escalate: stop with a useful explanation and supporting evidence.

Bind approvals to the exact action and parameters. An approval to refund £20 must not become permission for a later £200 call. Expire old approvals, and invalidate them when the underlying order or proposed action changes. Keep a kill switch outside the agent's own control.

3. Treat retrieved text as untrusted input

Prompt injection can arrive in a website, email, document or tool response. A malicious passage may tell the agent to ignore instructions, disclose records or call an unrelated tool. Clear system instructions help, but they are not a security boundary. Enforce restrictions in application code and in the systems receiving requests.

Use destination allowlists, scoped credentials, output validation and data minimisation. Avoid handing the model raw secrets. Strip unnecessary sensitive fields before retrieval and keep internal instructions separate from external content. If browsing is enabled, restrict network destinations and protect internal services from unintended access.

For changes with side effects, design idempotency: retrying the same action should not create a second payment, email or order. Record a unique operation identifier, check whether it has already completed, and distinguish a timeout from a confirmed failure. Agents make ordinary distributed-system problems more frequent, not less relevant.

4. Test the trajectory, not just the answer

Evaluate the complete sequence of decisions. Did the agent use the right customer record? Did it ask for approval? Did it stop after an unavailable tool? A polished final message can conceal a harmful intermediate action. Logs should capture tool names, validated arguments, results, timestamps and approval references, with sensitive data redacted.

Frameworks such as LangGraph can help represent stateful execution and human checkpoints. Provider SDKs can reduce integration work around tool calling. Neither choice supplies your business policies automatically. Compare checkpoint recovery, tracing, deployment requirements and vendor portability before committing.

Start in shadow mode: let the agent propose actions while the existing process remains authoritative. Then enable low-risk, reversible actions for a limited group. Measure task completion, incorrect actions, escalation quality, cost per task and time saved after review. A high escalation rate may be sensible early on; silent mistakes are not.

Further reading: LangGraph documentation and the OWASP GenAI Security Project.