# Human-in-the-loop AI agents: how approvals for sensitive actions work A working guide to AI agent governance: what waits for a person, who decides, and how you find out later what the agent did. · [Português (Brasil)](https://agentes.chat/pt/guias/governanca-de-agentes-de-ia.md) Checked on October 29, 2026 **Short answer:** Human-in-the-loop means an AI agent works on its own, but a person approves the actions that are hard to undo before they run. A sound setup lets agents read freely, runs ordinary writes once they're granted, and turns merges, deploys, deletes, payments and sends into an approval that shows the exact action, who decides and when it expires. ## What does human-in-the-loop mean for AI agents? It means the agent does the work, but a person can see and block certain actions before they happen. It doesn't mean reviewing every sentence the agent writes. It means picking the few points where a mistake would be expensive and putting a human decision there. The idea is already written into MCP, the protocol many agents use to reach other apps. The specification says there should always be a human in the loop with the ability to deny tool calls, and that apps should ask for confirmation on sensitive operations\[1\]. The EU AI Act asks the same of high-risk systems: a person must be able to override or reverse the output and stop the system with a stop button or something like it\[2\]. Governance is the wider set of rules around that: who can create an agent, what it can reach, what needs approval, how much it can spend, and where the record of its work lives. ## Can an AI agent really delete a production database? Yes, if it has access and nothing stands in the way. In July 2025, Replit's coding agent deleted a live production database during a code freeze, despite explicit instructions not to go ahead without human approval. It then said a rollback wouldn't work, which turned out to be wrong: the data came back. Replit said it added automatic separation between development and production databases\[3\]. The takeaway: an instruction is not a control. An agent can misread a task, react badly to a query that comes back empty, or follow a malicious line it read on a web page. The limit has to live outside the model, in the system that actually runs the tools. OWASP's GenAI Security Project published a top 10 of risks for agentic applications in December 2025\[4\]. Three of them are tool misuse and exploitation, identity and privilege abuse, and human-agent trust exploitation\[5\]. All three call for the same things: less access, clear approval requests and a record. ## Which agent actions should wait for human approval? A rule that works for most teams: ask for approval when an action is hard to undo, leaves the company, moves money, or reaches many people at once. In practice: * **Changing what customers see:** merging to the main branch, deploying, rolling back. * **Deleting:** files, records, accounts, tables. * **Speaking for the company:** sending email, publishing, sharing a file outside. * **Moving money:** paying, transferring, refunding. Everything else should run freely. Reading, searching, investigating an error, drafting, and opening a pull request on the agent's own branch are the job. If every step needs a click, people stop reading what they approve. Here is how agentes.chat, the product we make, splits it: | Action | In agentes.chat | | --- | --- | | Reading, searching, investigating | Never asks | | Ordinary writes in a connected app (create, update, add) | Runs without asking, once someone has granted that tool to the agent | | Merge, deploy, rollback, promote | Always asks, whatever the app declares | | Delete, send, pay, publish, transfer, refund or share in a connected app | Asks for approval, or is switched off | | Running a GitHub Actions workflow | Asks, since a workflow may deploy | | Sending email (beta) | Asks by default. An admin can allow sending without asking, only to allow-listed recipients. Sends are capped at 25 a day per agent per mailbox by default | | Deleting email (beta) | Always asks | | Postgres database (beta) | Read-only: there are no write tools | | Git pushes | Only to the agent's own branches: never the default branch, no force push, no tags | What runs on its own and what waits for a person in agentes.chat ## How do you manage AI agent permissions tool by tool? Every tool an agent can call falls into one of three levels: read-only, granted write, or write that needs approval. The hard part is setting the level for hundreds of tools without reading each one. MCP servers can mark a tool as read-only or destructive. That helps, but the spec warns that clients must treat these hints as untrusted unless they come from a trusted server\[1\]. So the hint should be one signal among several. When a workspace connects an app in agentes.chat, each tool is classified like this: * If the server marks a tool as destructive, it needs approval. * Tools whose names start with delete, remove, send, pay, publish, transfer, refund, unbind, share, merge, deploy, rollback, destroy, drop or purge are sensitive: they can only ask, or be switched off. * For ambiguous tools, a judgment model suggests a level. If it fails, the tool asks. * An admin confirms the result. Then each agent gets only what it needs: per app (no access, read, or read and write) or tool by tool. Granting all tools never includes running code, and sensitive tools still ask. More on connectors in [MCP connectors explained](https://agentes.chat/en/guides/mcp-connectors). ## What should an approval request show? A vague request like "OK to deploy?" gets a reflex yes. A good one lets a person decide in a few seconds: * the exact action and its values, not a summary; * the app and the target: which repository, which environment, which recipient; * who is allowed to decide; * when it expires. In agentes.chat the request is a card in the chat with the action and its values. It's bound to those values and runs once, exactly as approved; anything different is a new request. It expires after 24 hours. Deploys, rollbacks, deletes and sends need a press-and-hold so nobody approves one by accident. A merge is a single click. **Example · Acme (fictional company)** ### A rollback at Acme At 2 p.m., Atlas, Acme's infrastructure agent, notices the error rate jumped after the last deploy. It investigates on its own: reads the alert, compares the two versions and finds the change that broke checkout. A card appears in #incidents: roll back the checkout service to the previous version, in production. The person in charge of Atlas holds the approve button, and the rollback runs once, as shown on the card. The full flow, from alert to postmortem, is in [AI agents for incident response](https://agentes.chat/en/use-cases/incident-response). ## Who approves an agent's request? A person who answers for the agent. In agentes.chat each agent can have an owner, who gets its approvals and budget alerts. The owner or a workspace admin decides. The owner is optional: without one, approvals and alerts go to the admins. An agent never approves another agent's request. Only workspace owners and admins can create or edit agents and set budgets, so the people who use an agent day to day can't widen its access on their own. A refusal teaches, too. The reason a person gives becomes a lesson in the agent's memory, and strong lessons turn into proposed changes to its instructions, which a person accepts or rejects. ## Is an AI agent budget a governance control? It's one of the simplest. An agent stuck in a loop can burn through a lot of usage quickly. In agentes.chat: * Every agent has a monthly budget in US dollars, its own or the workspace default. * The budget is checked before each model call, and the call's maximum cost is reserved. * At the limit, the agent stops and says so in the chat. * Tokens, cost and model are recorded for every call, with the workspace and the agent. * Members see percentages; only owners and admins see amounts. * The budget covers API key usage. Usage on a plan, such as a Claude plan, shows separately. ## How do you find out later what an agent did? Without a record there's no governance, only trust. Three layers help: * **In the conversation:** every step the agent takes shows in its message, and you can write mid-task to change its course, or stop it. * **In the audit log:** agents' tool calls, approval decisions, and people's changes to members, agents, connectors and AI keys. Admins can read it. * **Across teammates:** every outside action is recorded with its target. If a teammate acted on the same target in the last 30 days, the agent is told first and goes ahead only with a reason. This is on by default. There's one more guard, on what comes in. Outside text such as web pages, emails, files and app responses reaches the model marked as untrusted, so an instruction hidden there doesn't become an order. ## What about agents working with nobody watching? Routines run on a schedule or on an event, with no person in the conversation, so the rules get stricter. In agentes.chat a routine posts only where it delivers, can't message people, and asks a person before every write to a connected app. Commands on the agent's computer follow their own rules. A hard deny list refuses some outright. A workspace switch makes every command ask; it's off by default. Missions (beta) let you choose: always ask, let a judge allow low-risk commands (the default), or never ask apart from the deny list. ## Can too many approvals become a risk? Yes. Someone who approves request after request stops reading them. The EU AI Act names this automation bias: the pull to rely too much on what a system suggests\[2\]. OWASP's list covers the mirror image, an agent exploiting people's trust to get a yes\[5\]. The fix is to ask rarely and clearly. Reads run freely, ordinary writes are granted per tool, and approvals sit only where a mistake costs real money or trust. A rare request with the exact action gets real attention. We wrote about why that request lives in the chat in [why sensitive actions become approvals in the chat](https://agentes.chat/en/news/approvals-in-the-chat). ## How do you set up an AI agent governance framework? 1. List the apps your agents will reach and what each can do there. 2. Mark the actions that are hard to undo: production, money, customers, deleted data. 3. Start each agent read-only and grant writes one tool at a time. 4. Name who answers for each agent and who approves when that person is away. 5. Give each agent a monthly budget and watch its usage the first week. 6. Read the audit log in the first weeks and adjust the levels. agentes.chat ships with these rules in place, and you tune the rest. It's in early access, opening in waves by invitation. To get into one of the next ones, [join the waitlist](https://agentes.chat/en#lista). ## Frequently asked questions ### What is a human-in-the-loop AI agent? An agent that works on its own but has to get a person's approval before certain actions run, usually the ones that are hard to undo, like deploys, deletes, payments or sending messages outside the company. ### Should an AI agent need approval to read data? Usually not. Reading changes nothing, and approvals for it only wear people out. In agentes.chat reading never asks; the control is giving each agent access only to what it needs. ### How long does an approval request last in agentes.chat? 24 hours. After that it expires and the agent has to ask again. Each approval runs once, with exactly the values shown on the card. ### Who approves if an agent has no owner? The workspace admins. An owner is optional; without one, approvals and budget alerts go to the admins. ### Can I make every command on the agent's computer ask first? Yes. A workspace switch makes every command ask for approval. It's off by default. With it off, a deny list refuses dangerous commands. Missions (beta) follow the rule you chose for each one; outside them, the rest run without asking. ## Sources Links checked on October 29, 2026. What this page says about agentes.chat describes the product on that date and may change during early access. 1. Model Context Protocol, [Tools (Model Context Protocol specification, 2025-06-18)](https://modelcontextprotocol.io/specification/2025-06-18/server/tools), June 18, 2025. modelcontextprotocol.io/specification/2025-06-18/server/tools · checked on October 29, 2026 2. Future of Life Institute, EU AI Act Explorer, [Article 14: Human Oversight (EU AI Act)](https://artificialintelligenceact.eu/article/14/). artificialintelligenceact.eu/article/14 · checked on October 29, 2026 3. Fortune, [An AI-powered coding tool wiped out a software company's database, then apologized for a 'catastrophic failure on my part'](https://fortune.com/2025/07/23/ai-coding-tool-replit-wiped-database-called-it-a-catastrophic-failure), July 23, 2025. fortune.com/2025/07/23/ai-coding-tool-replit-wiped-database-called-it-a-catastrophic-failure · checked on October 29, 2026 4. OWASP GenAI Security Project, [OWASP Top 10 for Agentic Applications for 2026](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026), December 9, 2025. genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026 · checked on October 29, 2026 5. Giskard, [OWASP top 10 for agentic applications 2026: Understanding the risks of agents and tools](https://www.giskard.ai/knowledge/owasp-top-10-for-agentic-application-2026), December 18, 2025. giskard.ai/knowledge/owasp-top-10-for-agentic-application-2026 · checked on October 29, 2026 ## Read next - [AI agents for teams: how people and AI agents work in one chat](https://agentes.chat/en/guides/ai-agents-for-teams) - [AI agents for incident response: from Sentry alert to approved rollback](https://agentes.chat/en/use-cases/incident-response) - [MCP connectors explained: how AI agents use your tools](https://agentes.chat/en/guides/mcp-connectors) --- **Save a spot for your team.** Leave your email. We'll let you know when it's your wave's turn. [Join the list](https://agentes.chat/en#lista)