AI Agents Are Entering Your Tools: Three Rules to Set Before You Let Them Act
By Anis Hammouche·July 6, 2026
An AI agent does not just answer. It acts inside the tools you plug it into, yours or a client's, so its mistakes no longer stay in a chat window. They land in the system. Before you let one run, write down three things: what it is allowed to do, what data it sees, and which actions wait for a human.
Take Léa, a freelance developer (an invented case, like every detail of this example). A two-person online ceramics shop asks her to connect an agent to its support inbox. The client says "it can do everything". Léa wonders what "everything" means the day the agent replies to the wrong customer, or refunds an order that should not have been refunded.
From an assistant that answers to one that acts
A classic chatbot works in a closed loop. You describe a problem, it produces text, and you decide what to do with it. Nothing moves in your systems without your action. An agent, by contrast, is given access to tools and a goal, then chains actions to reach it.
Two Google announcements at the end of June 2026 show the direction. On 24 June, Google introduced computer use as a built-in tool in Gemini 3.5 Flash: developers can build agents that see a screen, reason about it and act in a browser, on mobile or on a desktop. On 30 June, Google announced updates to Gemini Spark: new connected apps, including Canva, Dropbox, Google Tasks and Google Keep, support for custom MCP servers, real-time topic tracking, and a Mac version in beta, limited to Google AI Ultra subscribers in the US. I describe these announcements from Google's own pages, not from testing them.
You may never use either product. What matters is the pattern: the assistant no longer writes a draft you read over. It sorts files, sends a message, updates a record. Every action touches reality, not a draft.
Why acting is worth more, and costs more, than answering
A large part of work is moving information from one tool to another: reading a request, finding a file, updating a sheet, telling someone. An agent that runs this shuttle removes the most repetitive part, the one where a human acts as a bridge between two pieces of software.
But what gives it value also creates its risk. A chatbot that gets it wrong produces a false sentence you correct before use. An agent that gets it wrong carries out a false action in a real system: it writes bad data, sends a message to the wrong person, changes something it should not have touched.
So the right question is not "is the agent capable", but "what happens when it gets it wrong, and who stops it in time". For Léa it is also a question of responsibility: her client is the one who will call her.
A chatbot that answers or an agent that acts: what really changes
| Dimension | Chatbot that answers | Agent that acts |
|---|---|---|
| What it does | Produces text, you decide next | Carries out actions in the tools |
| Usefulness | Saves you writing and research | Saves you the full execution of a task |
| Risk | A false answer, fixed before use | A false action, already in the system |
| What to frame | Little: you stay the last link | A lot: rights, data, action validation |
The right column is not the left column with more power. It is a different regime of responsibility. With a chatbot, you are always the last link before action. With an agent, that link disappears by default, unless you deliberately put it back.
Three rules to set before you let an agent act
Framing an agent does not take deep technical expertise. It takes three questions, settled in order. Google says much the same about its own tool: in the computer use announcement, it offers optional safeguards (require explicit confirmation for sensitive or irreversible actions, stop the task if an indirect prompt injection is detected) and recommends combining them with sandboxing, human-in-the-loop verification and strict access controls. An indirect prompt injection is an instruction hidden in content the agent reads, such as an email or a web page, which it mistakes for an order.
OWASP, which maintains the reference list of risks for applications built on language models, files this danger under the name "Excessive Agency" and gives it three causes: too much functionality, too many permissions, too much autonomy. Its examples look like Léa's case: a tool meant to summarise a mailbox only needs to read it, not delete or send messages, and a high-impact action should be confirmed by the user. The three rules below answer those three causes.
| Rule | The question to ask | For Léa's shop (invented case) |
|---|---|---|
| Rights | What can the agent access, and nothing more? | It reads and sorts support messages. It deletes nothing and does not touch the till. |
| Data | What does it see, and where does it go? | Emails contain names, addresses and order numbers. The client decides whether that data may go through the chosen provider. |
| Human validation | What never goes out on its own? | It prepares a draft reply. A person sends it, and approves every refund. |
Rights: what it can access. An agent should get only the access its task strictly needs. One that sorts incoming requests has no reason to delete files. If you connect it at a client's, ask for a dedicated account with a limited role rather than the owner's account: you then know exactly what it can do, and you can cut it off without touching anything else. An agent with broad rights "just in case" is a broad risk too.
Data: what it sees and handles. Before connecting an agent, know which data it will read and transform, and where that goes. Customer data is not handed over the way a harmless task list is. The question is concrete: if this data leaked or was changed by mistake, how bad would it be? For what a person pastes into a public assistant, read what you paste into free ChatGPT or Claude; for the categories never to hand over, there is what you should never hand to a public AI.
Human validation: what never goes out on its own. Not all actions are equal. Sorting a request or preparing a draft can run on its own. Sending a message to a customer, approving a payment, changing an official record should go through a human who confirms. You do not have to choose between "everything automatic" and "nothing automatic": you draw a line. Below it, the agent acts alone; above it, it proposes and a human validates.
These three rules do not slow the agent down, they make it deployable. To get them in writing, here is a sheet to fill in before you connect anything, for yourself or for a client.
Task given to the agent: [one sentence]
Tool where it acts: [name of the tool]
RIGHTS
- It can: [read / sort / write a draft]
- It cannot: [send / delete / refund / pay]
- Account used: [dedicated account with a limited role, not the owner's account]
DATA
- It reads: [types of data]
- Sensitive data in the batch: [yes or no, which]
- Where it travels: [provider, country if known]
- If one item leaked or changed by mistake: [the damage, in one sentence]
HUMAN VALIDATION
- It acts alone on: [list]
- It waits for a human to: [list]
- Who validates, and within what time: [first name, deadline]
- How to stop it: [button, access to remove]
Frequently asked questions
Is an AI agent just a more advanced chatbot? No, it is a different category. A chatbot produces text you then use, an agent carries out actions in the tools on your behalf. The difference is not power, it is responsibility: with a chatbot, you are the last link before action; with an agent, that link disappears by default. Deciding to put it back is exactly the work.
Do you need technical skills to frame an agent? Not for the core decisions. Setting allowed access, sorting sensitive data and deciding which actions pass through a human are decisions for whoever owns the business, not for a developer. The technical part comes after, to apply the frame you set: creating a limited-role account, for instance, usually takes help from whoever administers the tool. If no one sets that frame upstream, no tool will set it for you.
Is it risky to deploy an agent now? The risk comes from deploying without a frame. An agent with broad rights and no validation on sensitive actions is risky. The same agent, with minimal scope and human validation on what matters, becomes a tool you control. The right time to deploy is when the frame is written, not when the demo impresses.
Where do you start without opening everything at once? With a single, well bounded, low stakes task. You frame its rights, its data and its validation level, you run it, you watch. An agent that does one framed task well beats ten agents let loose everywhere with no scope.
Sources
- Google, Introducing computer use in Gemini 3.5 Flash (24 June 2026, read on 1 November 2026)
- Google, Gemini Spark updates: macOS launch, connected apps and more (30 June 2026, read on 1 November 2026)
- OWASP Gen AI Security Project, LLM06:2025 Excessive Agency (read on 1 November 2026)
Léa, her client and the ceramics shop are fictional.
The next step is Small dev tickets piling up: hand them to a coding agent, review the pull request, where the same three rules apply to an agent that touches code. I share this kind of framing in my newsletter, you can sign up right below.