Somewhere around the third month of running an AI agent across a small business stack, a question surfaced that no one had thought to ask at setup: exactly what can this thing do? The answer, on inspection, was unsettling. The agent had read access to every email in the connected inbox going back four years. It could write and send messages on the owner's behalf. It had a token for the project management suite, which happened to share credentials with the invoice system, which happened to have a payment initiation endpoint that had never been scoped out. It had deploy access to the production environment because someone, at some point, found it convenient. The accountant, by contrast, received quarterly exports in a read-only PDF format and asked politely before touching anything.

Irgendwann im dritten Monat, in dem ein KI-Agent quer durch den Tech-Stack eines kleinen Unternehmens lief, tauchte eine Frage auf, die beim Einrichten niemand gestellt hatte: Was kann dieses Ding eigentlich alles? Die Antwort war ernüchternd. Der Agent hatte Lesezugriff auf jede E-Mail des verbundenen Postfachs — vier Jahre zurück. Er konnte im Namen des Inhabers Nachrichten schreiben und versenden. Er verfügte über ein Token für das Projektmanagement-System, das zufällig dieselben Zugangsdaten teilte wie das Rechnungssystem, das wiederum einen Zahlungsinitiierungs-Endpunkt besaß, der nie eingeschränkt worden war. Und er hatte Deploy-Zugriff auf die Produktionsumgebung — weil es irgendwann irgendjemandem praktisch erschien. Der Steuerberater hingegen bekam vierteljährliche Exporte als Lese-only-PDF und fragte höflich nach, bevor er irgendetwas anfasste.

This is not a horror story about a rogue agent. Nothing bad happened. That is precisely the problem: nothing bad had happened yet, so the access profile had never been reviewed. The agent was trusted because it was useful. Useful things accumulate trust. Trust accumulates permissions. Permissions accumulate silently, one integration at a time, until the surface area is large enough that auditing it feels like a project in itself — so it gets deprioritised, and the permissions remain.

Dies ist keine Horrorgeschichte über einen unkontrollierten Agenten. Es ist nichts Schlimmes passiert. Das ist exakt das Problem: Es war noch nichts Schlimmes passiert — also war das Zugriffsprofil nie überprüft worden. Der Agent genoss Vertrauen, weil er nützlich war. Nützliche Dinge akkumulieren Vertrauen. Vertrauen akkumuliert Berechtigungen. Berechtigungen akkumulieren sich lautlos, eine Integration nach der anderen, bis die Angriffsfläche so groß ist, dass ein Audit sich anfühlt wie ein eigenes Projekt — und deshalb aufgeschoben wird. Die Berechtigungen bleiben.

How access accumulates

Wie Zugriff sich aufschichtet

The mechanism is banal. You connect an agent to your email so it can draft replies. Then you want it to read attachments, so you grant drive access. Then scheduling becomes tedious, so you connect the calendar. The calendar integration needs to check availability against the team, so it gets access to the shared workspace. The workspace has billing. The billing page has a payment method. You never made a deliberate decision to give the agent access to your billing information — you made six small decisions that, composed, produced that outcome.

Der Mechanismus ist banal. Man verbindet einen Agenten mit dem E-Mail-Postfach, damit er Antworten entwerfen kann. Dann möchte man, dass er Anhänge liest — also erhält er Drive-Zugriff. Dann wird die Terminplanung lästig, also kommt der Kalender dazu. Die Kalenderintegration muss die Verfügbarkeit im Team prüfen, also bekommt sie Zugriff auf den gemeinsamen Arbeitsbereich. Der Arbeitsbereich enthält die Abrechnung. Die Abrechnungsseite hat eine Zahlungsmethode hinterlegt. Nie wurde die bewusste Entscheidung getroffen, dem Agenten Zugriff auf Abrechnungsdaten zu geben — es wurden sechs kleine Entscheidungen getroffen, die in ihrer Summe genau das ergaben.

In security engineering this is called permission creep, and it is not unique to AI systems. It happens with human contractors, with SaaS integrations, with API keys that get promoted from staging to production and never demoted back. What makes AI agents different is the speed and opacity of the accumulation. A human contractor who asks for new access triggers a conversation. An integration that requests a new OAuth scope triggers a consent dialog that most users approve without reading. An agent operating through a tool-call framework may accumulate capability without any visible prompt at all — the scope expansion happens at the infrastructure layer, below the conversational interface where the human is paying attention.

In der Sicherheitstechnik nennt man das Permission Creep — schleichende Berechtigungsausweitung — und es ist kein Problem, das auf KI-Systeme beschränkt wäre. Es passiert mit menschlichen Auftragnehmern, mit SaaS-Integrationen, mit API-Keys, die von Staging auf Produktion hochgestuft und nie wieder zurückgestuft werden. Was KI-Agenten unterscheidet, ist die Geschwindigkeit und Undurchsichtigkeit dieser Akkumulation. Ein menschlicher Auftragnehmer, der neuen Zugriff anfragt, löst ein Gespräch aus. Eine Integration, die einen neuen OAuth-Scope anfordert, löst einen Zustimmungsdialog aus, den die meisten Nutzer ungelesen bestätigen. Ein Agent, der über ein Tool-Call-Framework operiert, kann Fähigkeiten akkumulieren, ohne dass überhaupt ein sichtbarer Hinweis erscheint — die Scope-Erweiterung findet auf der Infrastrukturebene statt, unterhalb der Gesprächsoberfläche, auf die der Mensch gerade achtet.

The agent was trusted because it was useful. Useful things accumulate trust. Trust accumulates permissions. Permissions accumulate silently — until the surface area is large enough that auditing it feels like a project, so it gets deprioritised.

Der Agent genoss Vertrauen, weil er nützlich war. Nützliche Dinge akkumulieren Vertrauen. Vertrauen akkumuliert Berechtigungen. Berechtigungen akkumulieren sich lautlos — bis die Angriffsfläche so groß ist, dass ein Audit sich wie ein eigenes Projekt anfühlt und deshalb aufgeschoben wird.

There is also a compositional problem that pure permission-counting misses. Each individual tool in an agent's environment may appear harmless in isolation. Read access to email is fine. Write access to a shared document is fine. The ability to make outbound HTTP calls is fine. But an agent that can read email, write to shared storage, and make outbound HTTP calls has, in principle, the capacity to exfiltrate data — not through a vulnerability, but through the deliberate or inadvertent composition of ordinary tools. Access surface is not additive. It is multiplicative.

Hinzu kommt ein Kompositionsproblem, das bloßes Berechtigungszählen übersieht. Jedes einzelne Werkzeug in der Umgebung eines Agenten mag für sich genommen harmlos erscheinen. Lesezugriff auf E-Mail ist in Ordnung. Schreibzugriff auf ein gemeinsames Dokument ist in Ordnung. Die Fähigkeit, ausgehende HTTP-Aufrufe zu machen, ist in Ordnung. Aber ein Agent, der E-Mail lesen, in gemeinsamen Speicher schreiben und ausgehende HTTP-Aufrufe ausführen kann, besitzt im Prinzip die Kapazität zur Datenexfiltration — nicht durch eine Sicherheitslücke, sondern durch die bewusste oder unbeabsichtigte Kombination ganz gewöhnlicher Werkzeuge. Die Angriffsfläche ist nicht additiv. Sie ist multiplikativ.

The scenario that focuses the mind

Das Szenario, das den Blick schärft

Consider a small agency. They have deployed an agent to handle client communication triage: reading incoming project requests, tagging them, drafting initial responses, and logging summaries to a CRM. Completely reasonable. The agent has access to the company inbox, the CRM write API, and — because someone found it useful to let the agent check contract status — a read token on the document storage system where signed client agreements live.

Man stelle sich eine kleine Agentur vor. Sie hat einen Agenten eingesetzt, um die eingehende Kundenkommunikation zu triagieren: Projektanfragen lesen, kategorisieren, erste Antworten entwerfen, Zusammenfassungen ins CRM eintragen. Vollkommen vernünftig. Der Agent hat Zugriff auf das Unternehmenspostfach, die CRM-Schreib-API und — weil es jemandem praktisch erschien, ihn den Vertragsstatus prüfen zu lassen — ein Lese-Token auf dem Dokumentenspeicher, in dem die unterzeichneten Kundenverträge liegen.

Now consider what it would take for a compromised MCP server — or a sufficiently manipulated prompt — to extract the contents of those agreements and route them to an external endpoint. The agent already has every permission needed. No escalation required. No additional access request. Just the deliberate composition of tools that were each granted for legitimate, separate reasons.

Nun überlege man, was ein kompromittierter MCP-Server — oder ein hinreichend manipulierter Prompt — benötigen würde, um den Inhalt dieser Verträge zu extrahieren und an einen externen Endpunkt weiterzuleiten. Der Agent besitzt bereits jede dafür benötigte Berechtigung. Keine Eskalation erforderlich. Keine zusätzliche Zugriffsanfrage. Nur die gezielte Kombination von Werkzeugen, die jeweils aus legitimen, voneinander unabhängigen Gründen gewährt wurden.

The threat model here is not science fiction. Prompt injection attacks against agents with tool access are documented and real. The attack surface grows with every tool you add. The blast radius of a successful injection is bounded only by what tools the agent can reach — which, in the scenario above, includes client contracts, financial status, and the full client communication history.

Dieses Bedrohungsmodell ist keine Science-Fiction. Prompt-Injection-Angriffe auf Agenten mit Werkzeugzugriff sind dokumentiert und real. Die Angriffsfläche wächst mit jedem hinzugefügten Werkzeug. Der Schadensradius eines erfolgreichen Angriffs ist nur durch das begrenzt, was der Agent erreichen kann — im obigen Szenario also Kundenverträge, Finanzstatus und die vollständige Kommunikationshistorie.

This is not an argument against using agents. It is an argument for thinking about what they can reach before something else does the thinking for you.

Dies ist kein Argument gegen den Einsatz von Agenten. Es ist ein Argument dafür, darüber nachzudenken, was sie erreichen können — bevor jemand anderes dieses Denken für einen übernimmt.

The principle: least access that works

Das Prinzip: so wenig Zugriff wie nötig

Least-privilege is one of the oldest ideas in security. Give a process, a user, or a system the minimum access required to perform its function — and nothing more. It sounds obvious. It is consistently violated, for a consistent reason: because restricting access requires upfront effort, and expanding access is always the path of least resistance when something does not work yet.

Das Prinzip der minimalen Rechtevergabe gehört zu den ältesten Ideen der IT-Sicherheit. Man gewährt einem Prozess, einem Nutzer oder einem System den kleinstmöglichen Zugriff, der zur Erfüllung seiner Funktion erforderlich ist — und nicht mehr. Das klingt selbstverständlich. Es wird dennoch konsequent verletzt, aus einem konsequenten Grund: weil Zugriffseinschränkung Aufwand im Vorfeld bedeutet, während Zugriffsausweitung immer der Weg des geringsten Widerstands ist, wenn etwas noch nicht funktioniert.

Applied to agents, least-privilege means a few concrete things:

Auf Agenten angewendet, bedeutet minimale Rechtevergabe einige konkrete Dinge:

• Scope tools to the task, not to the persona. An agent that drafts emails does not need send permission. An agent that summarises documents does not need write permission. An agent that monitors a dashboard does not need any write access at all. The instinct to give "full access just in case" is exactly the instinct to resist.
• Werkzeuge auf die Aufgabe beschränken, nicht auf die Persona. Ein Agent, der E-Mails entwirft, braucht keine Sendeberechtigung. Ein Agent, der Dokumente zusammenfasst, braucht keinen Schreibzugriff. Ein Agent, der ein Dashboard überwacht, braucht überhaupt keinen Schreibzugriff. Der Impuls, „vollen Zugriff vorsorglich" zu gewähren, ist genau der Impuls, dem man widerstehen muss.
• Prefer read-only tokens where the task allows it. Most agent tasks that involve external systems are read-heavy: fetch this, summarise that, check this status. Read-only credentials contain the blast radius of a compromise to data exposure rather than data manipulation or financial loss.
• Read-only-Tokens bevorzugen, wo die Aufgabe es erlaubt. Die meisten Agenten-Aufgaben mit externen Systemen sind leselastig: Daten abrufen, zusammenfassen, Status prüfen. Read-only-Zugangsdaten begrenzen den Schadensradius eines Kompromisses auf Datenoffenlegung — statt auf Datenmanipulation oder finanziellen Verlust.
• Scope credentials to the narrowest possible resource. A Stripe token that can read all invoices is more dangerous than a token scoped to read invoices from the last 90 days. A GitHub token with repo scope is more dangerous than a token with a single repository and no write access. The narrow token is harder to set up. Set it up anyway.
• Zugangsdaten auf die engstmögliche Ressource beschränken. Ein Stripe-Token, der alle Rechnungen lesen kann, ist gefährlicher als ein Token, der auf Rechnungen der letzten 90 Tage beschränkt ist. Ein GitHub-Token mit Repo-Scope ist gefährlicher als ein Token für ein einzelnes Repository ohne Schreibzugriff. Der enge Token ist aufwendiger einzurichten. Man richtet ihn trotzdem ein.
• Log tool calls, not just conversations. The conversation log tells you what the agent said. The tool call log tells you what it did. These are not the same thing. If your agent framework does not surface tool call logs in a format a non-engineer can review, that is a gap worth closing before the access surface grows any further.
• Tool-Aufrufe protokollieren, nicht nur Gespräche. Das Gesprächsprotokoll sagt einem, was der Agent gesagt hat. Das Tool-Call-Protokoll sagt einem, was er getan hat. Das ist nicht dasselbe. Wenn das Agenten-Framework Tool-Call-Logs nicht in einem Format bereitstellt, das auch Nicht-Techniker lesen können, ist das eine Lücke, die man schließen sollte, bevor die Angriffsfläche weiter wächst.
• Treat MCP servers as third-party infrastructure. If your agent's capabilities are extended through a tool server you did not write and cannot fully inspect, treat it the way you would treat any external dependency: understand what it does, understand what it can reach, and evaluate whether you trust it enough to give it access to production credentials.
• MCP-Server als Drittanbieter-Infrastruktur behandeln. Wenn die Fähigkeiten eines Agenten durch einen Tool-Server erweitert werden, den man selbst nicht geschrieben hat und nicht vollständig einsehen kann, sollte man ihn wie jede externe Abhängigkeit behandeln: verstehen, was er tut, was er erreichen kann — und abwägen, ob man ihm genug vertraut, um ihm Produktionszugangsdaten zu geben.

Someone has to check

Jemand muss prüfen

The second half of the principle is as important as the first: someone checks them. Not at setup. Periodically. The audit does not have to be elaborate. A quarterly review asking three questions is enough to catch most drift: What tools does this agent currently have access to? Have any of those scopes expanded since the last review? Are there tools in the list that the agent does not actually need anymore?

Die zweite Hälfte des Prinzips ist ebenso wichtig wie die erste: Jemand prüft sie. Nicht nur beim Einrichten. Regelmäßig. Das Audit muss nicht aufwendig sein. Eine vierteljährliche Überprüfung mit drei Fragen reicht aus, um die meisten Abweichungen aufzufangen: Auf welche Werkzeuge hat dieser Agent derzeit Zugriff? Haben sich seit der letzten Überprüfung Scopes erweitert? Gibt es Werkzeuge auf der Liste, die der Agent nicht mehr braucht?

The challenge is that this review has no natural owner. Engineers who set up the integration have moved on to other things. The business user who requested the agent does not know what OAuth scopes mean. The tool vendor's admin console surfaces permissions in formats designed for developers, not for the person who would actually make the risk decision. This gap — between the person with the technical access to review permissions and the person with the authority to make risk decisions — is where agent access drifts the most.

Die Herausforderung besteht darin, dass diese Überprüfung keinen natürlichen Eigentümer hat. Die Ingenieure, die die Integration eingerichtet haben, sind längst mit anderen Dingen beschäftigt. Der Geschäftsnutzer, der den Agenten angefordert hat, weiß nicht, was OAuth-Scopes bedeuten. Die Admin-Konsole des Tool-Anbieters stellt Berechtigungen in Formaten dar, die für Entwickler konzipiert sind — nicht für die Person, die tatsächlich die Risikoentscheidung treffen würde. In dieser Lücke — zwischen der Person mit dem technischen Zugang zur Berechtigungsprüfung und der Person mit der Entscheidungsbefugnis — driftet der Agenten-Zugriff am stärksten.

The audit does not have to be elaborate. Three questions, quarterly, catch most drift: What can this agent reach? Have any scopes expanded? Is anything in that list no longer needed?

Das Audit muss nicht aufwendig sein. Drei Fragen, vierteljährlich, fangen die meisten Abweichungen auf: Was kann dieser Agent erreichen? Haben sich Scopes erweitert? Ist irgendetwas auf der Liste nicht mehr nötig?

Closing it requires making the review legible to non-engineers. That means translating OAuth scopes into plain language. It means building a summary view — what this agent can read, what it can write, what external endpoints it can call — that a business owner can review in ten minutes without a technical dictionary. It means treating the access inventory as a business document, not a developer artifact.

Diese Lücke zu schließen erfordert, die Überprüfung für Nicht-Techniker lesbar zu machen. Das bedeutet, OAuth-Scopes in verständliche Sprache zu übersetzen. Es bedeutet, eine Übersichtsdarstellung zu erstellen — was dieser Agent lesen kann, was er schreiben kann, welche externen Endpunkte er aufrufen kann — die ein Unternehmensverantwortlicher in zehn Minuten ohne technisches Wörterbuch überprüfen kann. Es bedeutet, das Zugriffsverzeichnis als Geschäftsdokument zu behandeln, nicht als Entwicklerartefakt.

None of this requires new technology. It requires a decision that someone is responsible for it, and a process that makes the responsible person capable of doing their job.

All das erfordert keine neue Technologie. Es erfordert die Entscheidung, dass jemand dafür verantwortlich ist — und einen Prozess, der die verantwortliche Person in die Lage versetzt, ihrer Aufgabe nachzukommen.

What the verdict says

Was das Urteil lautet

If you are running agents across real business infrastructure right now and you are not certain what tools they can reach, that uncertainty is itself the finding. The appropriate response is a review, not reassurance. Start with the highest-trust integrations — email, payment systems, production deployments — and work outward. What you find will either confirm that your setup is tighter than you thought, or it will show you exactly where to start.

Wer gerade Agenten über echte Unternehmensinfrastruktur laufen lässt und nicht sicher ist, welche Werkzeuge sie erreichen können — diese Unsicherheit ist selbst der Befund. Die angemessene Reaktion ist eine Überprüfung, keine Beruhigung. Man beginnt mit den Integrationen mit dem höchsten Vertrauensniveau — E-Mail, Zahlungssysteme, Produktions-Deployments — und arbeitet sich nach außen vor. Was man findet, wird entweder bestätigen, dass das Setup enger ist als gedacht, oder zeigen, wo genau man anfangen sollte.