When we built the first connectors for Thero, one number ran away from us: the number of tools. From the AI's perspective, a connected app is not a single unit, it breaks down into individual tools. Gmail brings tools for searching the mailbox, reading individual messages, creating drafts, and sending. A calendar brings tools for viewing, creating, and moving appointments. Add web search, people search, the internal knowledge base, documents. Add up what an organization connects, and more than 300 individual tools are available that an assistant, an agent, or a workflow can call.
To IT leaders, that sounds like a loss of control at first. The question came up in almost every early conversation: who decides what the AI is allowed to do? Followed immediately by the next one: does that decision still hold when an automated workflow runs at night and nobody is watching?
Our answer to both questions is not a feature list. It is a single architectural decision we made early: the rules live in exactly one place. In this article we describe that decision, the trade-offs behind it, and the form it takes in the product today.
Where do the rules live?
Once the first connectors were in place, there were three obvious places where rules could have lived. We rejected all three.
- In the prompt. "Please do not send emails without checking back" is not a rule. It is a wish. A model can overlook it, and a long context can crowd it out. Nobody builds a compliance argument on a wish.
- In each agent's configuration. Then an organization with twenty agents has twenty rulebooks. They drift apart. The dangerous one, in the end, is the agent nobody touched during the last update.
- At the connector as a whole. One switch per app is too coarse. If you turn off the mail integration because sending is risky, you lose reading as well. In practice this leads to exceptions, and exceptions are the beginning of shadow IT.
All three variants share the same construction flaw: the rule does not sit where the call happens. Someone has to remember it, copy it, or maintain it.
Our decision looks different. There is one organization-wide policy per tool. Not per app, not per agent, not per prompt. It is enforced in a single place: the layer every tool call passes through. Whether the call comes from a chat, from an agent, or from a workflow step makes no difference to the check. It is the same path and therefore the same rule.
There is no second rulebook that an agent could forget.
The sentence sounds banal. In security conversations it is still the argument that carries the most weight, because it ends the search for special cases.
Three states per tool
Every tool has exactly one of three states. In our experience, more is not needed and less is not enough.
| State | What happens on a call | Typical use |
|---|---|---|
| Allowed | The tool runs immediately. The call is recorded in the audit log. | Read access: searching a mailbox, viewing appointments, querying the knowledge base |
| Ask first | The call stops. A person sees the concrete parameters and approves or rejects. | Write access: sending, replying to, or forwarding an email |
| Blocked | The tool cannot be called anywhere in the organization, regardless of who asks. | Tools an organization rules out entirely |
We deliberately did not introduce further states. Every additional gradation, say "allowed, but only during office hours", would have to be explained, maintained, and audited. Three states fit in an administrator's head.
This is what the settings page looks like in our own environment:
The counter at the top of the page is real, it reads "236 erlaubt · 138 mit Nachfrage · 0 gesperrt": 236 allowed, 138 ask first, 0 blocked. Two things about this distribution are worth noting. First, most tools run without interruption, because read access needs no approval. Second, the number behind "blocked" is zero. Neither is a coincidence, both follow from two design lines we describe in the next sections.
Reading and writing are different risk classes
The most important line in the catalogue runs between reading and writing tools. Every tool is classified accordingly, and the interface shows the class openly: writing tools carry their own badge.
A read access changes nothing. It is also subject to the permissions that apply anyway, because the assistant reads only what the person asking could open themselves. A write access acts outward. A sent email cannot be recalled, and a moved appointment shows up in other people's calendars immediately.
The Outlook connector shows the pattern well. The reading tools are set to allowed, from searching the mailbox to reading individual messages. Sending, replying, and forwarding, by contrast, carry the "Schreibend" badge (writing) and the hand icon for the ask-first state. An agent can therefore reconstruct at any time what happened in a case. The moment it wants to send a message itself, the call halts and waits for a human.
The line follows outward effect, not convenience. The assistant may create an email draft without asking, it only lands in the drafts folder of the mailbox and does not leave the organization. Only when a message is actually to be sent does the call halt.
A look at search shows the other side of the same line:
Search tools only read, so they run without asking. Nobody has to approve a piece of research. Exactly that is what makes the ask-first state bearable elsewhere: it hits only the calls where something actually leaves the organization.
Why ask-first beats a block
The first reflex of many organizations is the block. Email sending by an AI? Better to switch it off entirely. We consider that the weaker solution, and the reason can be stated precisely: a block bans a capability wholesale. An ask-first rule decides a concrete case.
When an agent wants to send an email, the call stops and an approval card appears. It contains the recipient, the subject, and the full text, with the choice between approve and reject below. If nobody reacts within five minutes, the call counts as denied, the safe default is no. The reviewing person decides about exactly this one message to exactly this recipient. They do not have to answer the abstract question of whether an AI may ever send email. That abstract question is where approval processes in many companies get stuck.
Ask-first also produces evidence. Every decision is recorded: who approved or rejected which concrete call, and when. The vague statement "the AI is allowed to do that" becomes an auditable entry.
And the zero next to blocked? It is the consequence of this trade-off. A tool that asks for permission before every writing call rarely needs to be banned outright. The block remains as the hard instrument for tools an organization wants to rule out entirely. In our own environment we have not needed it to this day.
The policy on the running process
A policy that only existed on a settings page would be worth little. What matters is that it takes effect where work actually happens, and that you can watch it doing so.
In the "Agenten" overview, owners see all agents and workflows in the organization with their trigger. If an agent calls an ask-first tool in the middle of a run, the run halts at exactly that step and waits until someone has decided.
This is the point where the model becomes auditable in practice. A workflow that runs at three in the morning is subject to the same policy as a question in chat before lunch. There is no mode in which an agent is allowed to do more because it runs automatically. Whoever audits the environment therefore has no special cases to walk through. One rule applies per tool, there is one enforcement point, and the audit log records time, process, action, status, duration, and person for every call. The entries can be filtered and exported as CSV.
Changes stay central as well. If an administrator moves a tool from ask first to allowed, it applies to every caller from that moment on. No agent has to be reconfigured, no workflow touched.
What you can take away
Whatever platform you use, something can be derived from this architecture. Four review questions have proven useful in our conversations:
- Count tools, not apps. "We connected the mailbox" says nothing about whether the AI can send. Only the list of individual tools makes the risk visible and negotiable.
- Separate reading from writing. The two classes need different rules. Treating them the same makes you either too strict for research or too lax for sending.
- Prefer asking over blocking. An approval in the concrete case preserves the capability and produces evidence at the same time. A blanket block mostly produces workarounds.
- Ask where the rule is enforced. Does the same rule apply in chat, in agents, and in workflows? If the answer names several configuration places, several rulebooks exist, and one of them will eventually be forgotten.
More than 300 tools sound like a control problem. With one policy per tool, enforced in one place, they become three numbers any administrator can read at a glance. In our environment they stand at 236, 138, and 0 today.
See Thero live
Book a short demo. You talk directly to the founding team.