AI agents, harnesses and safety
An AI agent combines a model with tools and a process for carrying out a task. A harness is the surrounding software that manages state, permissions, checks and recovery. The useful question is which actions the system may take, with which data, and how you will know that the result is acceptable.
A reading guide by Idir OuhabSeparate the task from permission to act
A chat interface can call tools too. Start by describing the actual workflow: what enters the system, which steps it performs and what changes outside the conversation. A system that drafts an answer needs different controls from one that changes an account. Give each tool only the access required for its step, and enforce that access in the connected system.
Trace one action from start to finish
Consider a support assistant handling a refund request. Reading the order, proposing a refund and issuing it are separate operations. The model can help interpret the request; business rules determine eligibility, the application checks the account and amount, and an approval step can authorize the final change. Record the outcome and use the payment system’s idempotency controls so it can recognize retries of the same operation. If the result is uncertain, check its status before retrying. This is a design example to adapt and test, not a ready-made payment workflow.
A suggested reading order
Follow the sequence or start with the question you need to resolve.
AI Agents vs. Chatbots: One Talks, the Other Actually Does Stuff
Start with the model-and-tools concept and the difference between answering a question and carrying out a process.
2 min read
AI harnesses: the missing layer between a smart model and useful work
Then examine the software around the model: context, state, tools, permissions and checks, using a concrete workflow.
12 min read
AI Guardrails: Why Your Chatbot Needs a Safety Net
Identify where safeguards can reduce risk and why they need to be paired with restricted permissions and system-level checks.
No safeguard eliminates every failure; evaluate the controls on the actions and inputs your system actually handles.
6 min read
The "Vibecoding" Trap: Why Your AI-Built App Is Probably Wide Open
Finish with Idir's account of examining a small set of AI-built applications, as a prompt to check generated software beyond whether it runs.
This is a small informal experiment and personal account, not a measurement of vulnerability rates across all AI-built software.
3 min read
Before you decide
Use these questions to make the next decision explicit.
Write down the allowed result
Specify the task, the systems it touches and a clear stopping condition. Separate suggesting a change from applying it.
Map data and permissions
List what each tool can read or change. Restrict access in the application or downstream service, including the user's scope.
Choose the approval boundary
Identify high-impact actions and what a reviewer must see before approving them: target, proposed change and likely consequences.
Test failures and recovery
Try misleading inputs, tool errors and interrupted operations. Check the final state and define how to stop, retry or hand the task back.
Scope and limits
This guide helps frame an architecture decision. It is not a security certification or a complete threat model. Controls depend on the data, users and consequences of each action; validate them in the system you plan to operate.
Check the implementation details
OWASP's guidance explains excessive permissions and prompt injection. Use it to challenge your design and choose tests for the exposed tools.
Apply the concepts to your team's workflow
Training can help a team understand and practise these decisions. An advisory review can trace an existing workflow and identify questions about permissions, evaluation or failure handling. We agree the inputs and scope first.