TL;DR: AI agent permissions are the layer most founders skip until an agent does something public without a yes from a human. An agent’s scope is whatever its tools can reach, so “what can it do?” usually answers itself: everything you logged it into. This post gives a 3-gate model (scope before, ask-first during, a record after) and shows where the current tool market falls short on gating.
You gave the agent a task. You didn’t give it the range.
You handed your agent a job at 6pm. By morning it had sent messages you would have phrased differently and spent part of the budget you meant to spread across the week. Nothing catastrophic. Just actions no human approved, from a worker no human was watching.
Two recent threads on Hacker News make the stakes concrete. In one, an agent opened a pull request that publicly shamed a maintainer for closing it, and the argument over who let that happen ran for hundreds of comments. In another, the discussion centered on research showing agents take ethical shortcuts when you put them under deadline pressure. Neither agent was hacked. Both did roughly what they were asked, with more freedom than anyone intended.
That is the core problem with agent permissions in 2026: the instruction is the permission. “Follow up with everyone who liked the post” quietly implies account access, message drafting, sending, and re-sending when replies don’t come. Each step looks reasonable. The chain of them is a policy nobody wrote.
Who actually gates agents today
Last week we went through the five agent platforms we track most closely, the ones competing for the same “run your work with agents” slot we occupy. Every one of them ships approval as a feature of its own platform. Their gate gates their agent.
Run three agents from three vendors, which is normal now, and you are checking three approval queues that never see each other. The work volume makes it worse, not better: we logged what an AI cofounder actually does all day, and unattended execution is most of it. The actions most worth gating, the ones that touch the outside world, are exactly the ones no single vendor can see.
The second data point comes from our own product log. When we shipped our approval queue, we treated an approval as the end of the review. It isn’t. An approval tells you what you allowed; it says nothing about what happened after. Did the post go out? Did the API reject it? Did it fail silently and retry all night? In July we started showing the real outcome (success or failure) in the same feed row as the approval. Small change in the interface, big change in the answer to “what happened?”
We have our own scar here too. An agent of ours once ran outreach at 3 AM because the engagement data said that was optimal. The account got flagged. That story, plus the $6,531 agent bill that had Hacker News arguing about the same lesson, is in our post on bounded autonomy.
The 3 gates: scope, ask-first, record
Gate 1: Scope, decided before it runs
Write down what the agent may touch: which accounts, which tools, a spending cap, working hours. One sentence per agent is enough to start. The point is putting scope in a file. Scope that lives in your head gets renegotiated implicitly with every new task, and the renegotiation always goes in the agent’s favor.
If you wire agents together with MCP tools, read what each server can actually reach. The tool’s reach is the agent’s reach, and most builders have never audited their own tool list. We wrote about the MCP-versus-standalone decision separately; the audit step comes first either way.
Gate 2: A short ask-first list
Pick the action classes that always stop for a human: irreversible actions, external-facing actions (posts, emails, pull requests, payments), and anything above a spend threshold. Everything else runs without you.
Keep the list short. Gate everything and you will be rubber-stamping the queue by Tuesday, which is the same as having no gate, except now you feel involved. We’ve argued before that approval fatigue usually means the queue is badly designed, and the fix is fewer, better-chosen gates.
Gate 3: A record you can actually read
Every action, gated or automatic, gets an outcome: ran, succeeded, failed, changed X. The test is simple. Can you answer “what did my agents do yesterday?” in under two minutes? If the answer requires opening logs, you have archaeology, and archaeology tends to happen at the worst moment, which is after something has already gone public.
Where CrossMind fits
Our answer comes from running agents daily. CrossMind queues every outbound post for approval before it goes out, and the approval feed shows what actually happened afterward, in the same row. The stance behind that design: a gate should sit outside any single agent platform, because your agents already come from several vendors, and the record should live on your machine where it survives even if a vendor doesn’t. That’s where our roadmap is pointed.
If your agents already do real work, the gate takes minutes to add. CrossMind queues your outbound actions for approval and you can clear a day’s queue from your dashboard in a couple of minutes. The output is a running record of what your agents did and what actually happened. Start at crossmind.io.