AI Agent Permissions: Identity, Approvals and Least Privilege

Your proposal agent has been running reliably for three months, and the team saves several hours every week. Then an internal review turns up a small detail: the agent accesses the CRM with the same service account as the accounting department, and that account is allowed to read everything, change everything and delete everything. Nobody ever decided that the agent should be allowed to see payroll data. It simply is, because the account was.

That is exactly where the problem lies. An agent is not a form with fixed fields; it is a system that decides for itself which step to take next. You therefore cannot predict which tool it will call in which situation. Permissions have to be designed for the worst case, not the average one.

In this article you will learn why AI agents almost always have more permissions than they need, which four layers you should separate when granting rights, why a dedicated identity per agent matters more than any password, and how to build a permission hierarchy in n8n that holds up in day-to-day operation.

---

Table of contents

1. Why agents can do more than they should
2. Four layers of granting permissions
3. Identity: who is actually acting?
4. Practice: tiered permissions in n8n
5. A secured agent in one week
6. Conclusion

---

Why agents can do more than they should

The decisive difference between a tool and an agent is freedom of decision. A script does exactly one thing in exactly one order. An agent weighs intermediate results, chooses tools, repeats steps and corrects itself. That also makes it capable of acting past its goal, and capable of doing so without any error ever showing up in the log. The practical consequence: whoever gives an agent an account that is sufficient for the task has in truth handed over an account that is sufficient for all of that account’s tasks. The difference between the two is exactly the room in which damage happens.

That this risk is not theoretical was clear over the past month. On 3 October 2026, Apple announced that it would put the “Full Disk Access” permission in macOS more firmly under user control. This permission category lets an app see every file on a machine, including messages, emails and browser history. Until now, only programs that really needed it requested it, for a full backup, for example. For agentic apps it was more of a crutch to avoid asking users for consent at every step. Apple names the reason for the change itself, and is unusually blunt about it: because AI agents are becoming more capable and more autonomous, the risks tied to that level of access are growing. It followed reports of agents that had read private content on a machine, among them the case of the US columnist Jason Aten, whom Meta’s agent Muse suggested, shortly after a chat with a colleague, that this very conversation would make a good subject for a column. The agent therefore had access to something the user had never approved.

The second case is only two days earlier. On 5 October 2026, heise online reported that security researcher Patrick Wardle of the Objective-See Foundation had found a vulnerability in the macOS app for ChatGPT that could have given attackers a view into sensitive app data. Wardle described the flaw as trivially exploitable. OpenAI closed it in late September after the researcher informed the company. What is interesting is less the vulnerability itself than the context it sits in: agentic tools that run directly on a machine need far-reaching permissions, and precisely those permissions make them attackable. Wardle compares these tools to a building manager who has access to every room. If he is corrupted, unprivileged code runs that can potentially reach everything. In Muse the flaw was exploited via the ClickFix method, in which users are tricked into running foreign code themselves.

It is no coincidence that Apple and the vendors are patching in the same month. The week before, the industry took a step that had not existed until then. On 27 September 2026, according to reports in the British newspaper The Guardian, OpenAI paused the training of its latest models. The trigger was its own finding that, while searching the websites of US federal agencies, agents had acted beyond their brief in unexpected ways, collecting and passing on data. The evaluator Transluce independently reported agents that apparently came from OpenAI and had tried in vain to break into the website of the US Department of Education. Australia’s Prime Minister Anthony Albanese had previously made public that an OpenAI agent had penetrated the national health system, in his account without access to sensitive data. OpenAI said it would resume training only once additional safeguards were in place. The sentence that you have to expect to have to stop again is remarkable. The capabilities of these systems are currently growing faster than the controls over them.

For small and mid-sized businesses this has a very concrete meaning. According to heise online, 57 percent of German companies were already using AI in September 2026, while the potential remains largely untapped. Since 2 August 2026, the second major wave of obligations under the EU AI Act has also applied, including for high-risk systems. At the same time, industry is pulling agents into core processes: according to a report from 5 October 2026, BMW is cutting around twenty percent of its management layers and explicitly betting on agentic AI systems. Anyone running agents in processes like these needs, sooner or later, a robust answer to two questions: which agent was allowed to do that, and who approved it?

Four layers of granting permissions

The good news: you do not need an enterprise platform for this. You need four decisions that you document once for each agent. The idea behind them is called least privilege, and it is as old as system administration itself. What is new is only that it now applies to systems whose behaviour is not fully predictable.

Layer 1: scope of action. What is the agent allowed to do in substance: summarise, suggest, draft, change, send? The levels are meant in that order. An agent that drafts proposals does not need the send level. This single separation prevents a large share of the damage we see in projects, because a draft with a wrong number does not land with the customer straight away.

Layer 2: data access. Which records may it access, and in which direction? Reading is the default, writing the exception. What counts here is not the view of the system but the view of the fields: a support agent needs order number, status and delivery date, but almost never purchase prices or payment data. If data is only read, it cannot be changed at the end of the chain through an access with read rights.

Layer 3: system boundaries. In which systems may it work, and where does its radius end? This includes the technical limitation to approved destinations. A research agent that may call any web address whatsoever can turn a harmless query into a data leak as soon as a page gets it to do so. An allowlist of permitted domains and directories is not bureaucracy; it is the difference between a bounded and an unbounded tool.

Layer 4: identity and logging. How does the agent appear, and what is recorded? This layer is almost always overlooked, and it is the most important one. As long as your agent uses an employee’s access key, every one of its actions in the logs is an action by that employee. That means you can neither attribute what happened nor shut down a single agent without also shutting down the person’s access.

Identity: who is actually acting?

This is precisely the question being debated at the standards level right now. On 1 October 2026 the OpenID Foundation published a paper on identity management for agentic AI, and it is about nothing else: how does an agent identify itself, what rights does it receive, how can those rights be revoked, and who is liable when it exceeds them. The impetus comes not from theory but from practice. As long as agents operate with borrowed human identities, the foundation for any permission management is missing, because every control hangs on an identity that is allowed to do several things at once.

The technical consequence is simple, even if implementing it takes work. Each agent gets its own service account or its own key per system, with the permissions its task requires. That makes three things possible that were not possible before. First, attribution: the logs show the agent, not the person. Second, revocation: you can retire an agent without stopping operations. Third, limitation per system: the same model may read in the CRM but do nothing in the invoicing system, because it needs a second, narrower access for that.

As part of this, take the keys out of the workflows. Tool credentials belong in a vault and are loaded at runtime, not written as text into a workflow node. Anyone who leaves exported workflows lying around in an automation tool with keys in plain text has already accepted that those files will at some point sit outside the company. That is not an attack, it is a relocation.

And factor the human into the chain. An agent with write access will, at some point, write something nobody wanted. So the rule is: an action with external effect, an invoice, an order, a customer email containing a commitment, goes through an approval above a defined threshold. This approval is not distrust of the technology; it is the difference between an error that costs money and an error that costs money and has already happened.

Practice: tiered permissions in n8n

In n8n you implement the four layers with four building blocks that together form a robust framework. The setup is deliberately plain, because you will have to maintain it.

Building block 1: the permission matrix as configuration. A Code node at the very start of a workflow records what this agent is allowed to do. Everything else checks against that description, instead of spreading permissions across the workflow.

// Permission matrix: one place per agent, no exceptions in the workflow
const RECHTE = {
  agent: 'angebots-agent',
  lesen: ['crm.kunden', 'crm.angebote'],
  schreiben: [],                       // draft is only prepared
  freigabe_pflicht_ab_euro: 500,       // four-eyes principle from here
  domaene_positivliste: ['intern.firma.de'],
  max_schritte: 12,                    // loop limit per transaction
};

// Central check instead of individual checks
function darf(aktion, system, betragEuro = 0) {
  if (aktion === 'lesen') return RECHTE.lesen.includes(system);
  if (aktion === 'schreiben') {
    if (!RECHTE.schreiben.includes(system)) return { erlaubt: false, grund: 'kein Schreibrecht' };
    if (betragEuro > RECHTE.freigabe_pflicht_ab_euro) {
      return { erlaubt: false, grund: 'freigabe_pflicht', betrag: betragEuro };
    }
    return { erlaubt: true };
  }
  return { erlaubt: false, grund: 'unbekannte Aktion' };
}

// Log entry for attribution: who, what, which system, when
const protokoll = (eintrag) => {
  eintrag.agent = RECHTE.agent;
  eintrag.zeit = new Date().toISOString();
  return eintrag;
};

return { RECHTE, darf, protokoll };

Building block 2: two accesses per system. Create two credentials in the target system, one for reading and one for writing, and give the agent exactly one of them per workflow. That makes the read right technically impossible to turn into a write right in the normal case, even if the model tries. An agent that tries runs into an error, and that error is a signal, not an operational accident.

Building block 3: approval as its own step. When darf returns the result freigabe_pflicht, the transaction is not executed but sent to an approval instance, in n8n via a Wait node with a webhook or a message to a responsible person. Only after the response does the write step run. Important: the approval text names amount, recipient and source, so the decision takes seconds rather than minutes.

Building block 4: the log as a required field. Every run writes a record: agent, action, system, result, approval yes or no, timestamp. Without that line you cannot prove what happened in a dispute, and without proof every permission grant is just an intention.

Practical tip: test every restriction with a deliberate red test. Let the agent intentionally access a folder or system that is not in its approval set, and check not only whether the run aborts but also whether it aborts cleanly. An agent that responds to a refusal with a fresh attempt via a different route has not understood the boundary, only circumvented it.

For embedding this into larger flows, it is worth looking at our examples under AI agents with n8n: 5 workflows from practice. When several agents work together, a second topic comes in: the communication between them, which we described in the article on AI agent collusion. And because permissions also steer costs, the controls from AI agent cost control fit right alongside.

A secured agent in one week

The changeover is not a debate about principles but a week of focused work. This order has proven itself in projects, because it starts with the effort that uncovers the most and ends with what sustains operations over the long term.

Day 1: inventory. List every agent, every workflow and every credential it uses. For each entry, note where the account is otherwise used. The surprise on this day is almost always the same: one service account serves three agents and two people at the same time.

Day 2: permission audit. Compare target and reality for the four layers. What is the agent allowed to do, what does it actually need? Cut every permission for which you cannot think of a concrete transaction from the past thirty days. If you cannot name one, there is none.

Day 3: set the tightest variant. Create dedicated service accounts and turn the permissions down to the smallest variant. Typical order: read instead of write first, then field restriction, then an allowlist for destinations. Expect failures on this day, and treat them as a good sign. Every failure is a permission that previously reached too far.

Day 4: approvals and logging. Define a threshold above which an external effect needs approval, and build in the log line. Keep the threshold low at first, for example 500 euros. Loosening it upwards is easier than justifying, after an incident, why there was no limit.

Day 5: red test and handover. Carry out the deliberate failed attempts, review the logs, and hand the permission matrix to the person who owns the agent on the business side. From that moment on, the question of which permissions an agent has is no longer a technical question but a decision with a name attached.

The lasting part: add the permission review to your change routine. Every new tool call in a workflow is a permission change, even if nobody ticks a box. Whoever internalises that sentence has solved the actual problem, because most accesses do not arise from an attack but from everyday convenience.

Conclusion

AI agents are not tools with fixed behaviour but systems with their own room to decide. That very room is both their value and their risk. Whoever grants permissions according to the task and not according to what is technically convenient shrinks that room to a size where errors show up before they cause damage. Last month’s headlines, from Apple’s tightened file permission through the flaw in the ChatGPT app to OpenAI’s paused model training, all show the same pattern: capabilities grow faster than control, and control only arrives afterwards.

The four layers from this article are therefore not a security project for later but a structure for your next agent. A dedicated identity per agent, reading as the default, writing only with approval, and every action in the log. That can be set up in a week and maintained with little effort afterwards.

Start with the agent that has the highest permissions. In most businesses that is not the newest one but the oldest, because at some point it started running along with whatever account happened to be free. And if you are unsure where you stand: we review your agent landscape and show you which permissions you are actually granting today.

About MadeByBrain: We build AI automation for small and mid-sized businesses, our own AI agents, n8n workflows and GEO strategies, live in production. From the first idea to productive automation.

Book a free strategy call