AI agents: permissions and approvals

An agent that acts - and where it stays traceable who triggered what? WZ-IT builds agents with defined tools, approvals at the critical points and complete logging. See AI agents

With an assistant that only answers, the worst mistake is a wrong answer. With an agent that acts, it is a wrong action in a production system - and it was not predicted, because the agent chooses its route at runtime. This article covers the questions asked too late in agent projects: whose account the work happens under, what the agent may touch at all, where a human has to consent, and what ends up in the log. As of August 2026.

Contents

• Chatbot, workflow, agent: the difference is the route
• Whose account does the agent act under?
• A tool catalogue instead of full access
• Where a human has to consent
• What belongs in the log
• MCP: the interface that survives a model change
• What the legal frame requires

Chatbot, workflow, agent: the difference is the route

Marketing conflates the three terms although they carry different risks. The question that separates them is not how clever the system looks but who determines the path.

A chatbot answers from existing content and changes nothing. There is no path, only an answer. A mistake is a wrong answer: annoying, but reversible.

A workflow runs a chain of steps - open a ticket, send mail, write a record. You defined the sequence in advance; at most the model fills in fields. A mistake breaks the sequence or writes wrong values, but it is reproducible and therefore fixable.

An agent decides for itself, within set boundaries, which tools to use and in which order. You set the boundaries, not the route. A mistake is an action nobody predicted.

This is not an academic distinction but the basis of the estimate. A substantial share of what comes in as an agent project is in fact a workflow - and that is good news: cheaper, finished sooner, easier to audit. The honest classification belongs in the first conversation, not in a change request.

Whose account does the agent act under?

An agent that acts needs an identity in the target system. Which one it is determines what a single user can trigger through it - and this question is missing from most requirement lists.

One service account for everything. The agent gets a technical account holding every permission it might ever need. It is quick to set up and creates a union: through the agent, any user can indirectly trigger anything the service account is entitled to, including things they would not be entitled to themselves. Someone who asks the agent to "check the case handled by our colleague Müller" may get an answer they could never have retrieved themselves. This is only defensible if the agent does nothing that everyone may trigger anyway.

Pass through the requester's identity. The agent acts on behalf of the user who started it and inherits their rights in the target system. Someone who may not open a ticket in that queue cannot do it through the agent either. This costs more, because the target system has to support delegated identities - and it is the default, because rights stay where they are maintained anyway. You do not run a second permission world alongside your directory.

A separate account per task. For actions nobody triggers personally - nightly runs, system maintenance - the agent gets its own narrowly scoped account per task instead of one all-powerful account. An account allowed to check backups does not need to approve invoices.

In practice all three occur. The mistake is not using a service account - the mistake is using one without having worked out the union.

A tool catalogue instead of full access

An agent without tools is a chatbot. The question is how much surface the tools expose.

The convenient route is broad access - a database user, a full-scope API token - and the hope that the model behaves. That is the same construction as the prompt instruction in RAG systems and fails for the same reason: a request is not a boundary.

The construction that holds is a named tool catalogue: a list of permitted operations with defined parameters. "Open a ticket in queue X" is a tool; "run SQL" is not. What is not in the catalogue does not exist for the agent.

Three properties make a catalogue hold:

Narrowly scoped operations. The narrower the tool, the smaller the damage from misuse and the better the analysis afterwards. Ten specific tools beat one with ten parameters.

Writing tools are rare. The large majority of a catalogue should be read-only. Every writing tool is a deliberate decision with its own justification.

The permission check stays in the target system. A tool calls the regular interface, not the database behind it. That way the checks that already exist in the target system take effect - and you do not maintain a second permission logic inside the agent.

Where a human has to consent

Human oversight cannot be retrofitted. It comes from certain steps requiring approval and from a named person who grants it. That belongs in the architecture, not in a policy document.

The workable boundary: approval is needed for anything with outward effect or that cannot be undone without effort.

• Messages to customers, suppliers or authorities
• Changes to master data
• Movements of money of any kind
• Deletions
• Status changes with contractual consequences

The rule of thumb for borderline cases: if you cannot fix the mistake yourself in five minutes, an approval belongs in front of it.

Two design mistakes recur here. The first is approval as a formality - a dialogue that appears so often it gets clicked away. If an approval step comes up ten times a day, it is scoped wrongly; the action then belongs in a workflow with fixed rules rather than in an agent. The second is approval without context: whoever is to consent has to see what the agent intends to do and what it derives that from - not just a tool name.

What belongs in the log

What was not recorded cannot be evidenced later. For an agent the usual application log is not enough, because two facts are missing that can diverge: who triggered and under which identity it ran.

A usable entry records: trigger, executing identity, tool used, parameters passed, outcome, and for critical steps the person who approved. Plus the run as a whole - which tools in which order - so a chain of decisions can be reconstructed rather than only its last link. Langfuse records such runs as traces and is the usual building block for this in the open stack.

The log belongs on your infrastructure. A provider that mines the runs for its own purposes is not an option for internal processes - and in a dispute, a log you have no direct access to is of little use.

MCP: the interface that survives a model change

The Model Context Protocol is an open standard through which a model addresses tools and data sources uniformly. The benefit is economic rather than technical: a connection built once to your ticket system stays usable when you swap the model underneath. Given the pace at which models change, that decoupling is the real gain.

Two caveats belong with it. MCP standardises the route of access, not the permission - who may use which tools is still decided by your catalogue and the target system. And a standard does not remove the question of whom you trust with a server: a third-party MCP server inside your network is an access decision like any other.

Where an interface already exists - Zammad, n8n, ERP, CRM - it is usually the shorter route. Building a parallel world so an agent can talk to it rarely pays off.

What the legal frame requires

As orientation, not legal advice - and reflecting the position after the Digital Omnibus, in force since 27 July 2026.

Transparency already applies. Since 2 August 2026 it has to be recognisable that one is interacting with an AI system. For an agent that means more than a note in the chat window: an action it triggers should stay recognisable as such too. An email that looks as though a person wrote it is the mistake.

High risk is deferred, not lifted. The duties under Annex III apply from 2 December 2027, those under Annex I from 2 August 2028. Anyone planning an agent in HR, lending or similarly classified areas gains time - not a reprieve.

Oversight and logging are build decisions. Neither can be produced retroactively. Getting the approval points and the log right from the start means having the evidence when it is asked for.

Most business agents fall not under high risk but under transparency and documentation. Which class applies to your case is for your legal advisers; we supply the technical description their assessment rests on.

What this means for your project

The three decisions that drive the effort are made before the first line of code: which identity the work happens under, how narrowly the tool catalogue is scoped, and where an approval sits. Make them later and you build twice.

How permissions work in a system that only answers is covered in RAG with permissions - the mechanics there underpin everything an agent reads. What agents and automation do in general is placed in AI agents & automation, and the duties in overview are in The EU AI Act for companies. When an agent reaches internal documents and staff use it, co-determination comes into play - see AI assistants and the works council.