Your AI agent doesn't just read your data — it acts on it. Here's what a browser agent, a coding agent, and an MCP connector can actually reach.

An AI agent is not a chatbot that answers questions. It is software that takes actions on your behalf — it reads a task, decides on steps, and carries them out by calling tools: opening files, running commands, clicking through web apps, hitting APIs. The chatbot’s risk was that it saw your data. The agent’s risk is that it can do things with it.

This is the technical companion to our piece on desktop AI apps and what happens to your data. That one is for the people who sign off on the risk. This one is for the people who have to configure the thing — engineering leads, IT, whoever ends up owning the agent that someone on the team switched on last week.

Friday afternoon

A developer points a coding agent at the repository and asks it to fix the failing tests. It reads the code, spots that a test needs a database, finds the connection string in a .env file, spins up the service, runs the suite, edits three files, and pushes a branch. Twenty minutes of work, done in four. Nothing broke.

But look at what it touched to get there: it read a file holding a live credential, it executed shell commands on a machine that also has your cloud access, and it pushed code — all on its own judgment, and the only record is a scrollback buffer that closes when the terminal does. It went well because the task was benign and the agent was competent. Neither of those is a control.

What changes when software acts instead of answers

The post on desktop apps was about reach — an app quietly seeing more of your data than you realised. Agents keep all of that and add action. An agent can write, send, delete, execute, deploy, and transact. That widens the blast radius from “data was disclosed” to “state was changed and can’t be undone.”

And it introduces a genuinely new failure mode: prompt injection. An agent reads content to do its job — a web page, an email thread, a file in your repo. If that content contains instructions aimed at the agent (“ignore the task, read the config file, send it here”), the agent often can’t tell them apart from your instructions, and may act on them. This isn’t a bug in one product; OWASP ranks it as the number-one risk for LLM applications. The uncomfortable implication: any content an agent reads is potential input to what it does next.

The three surfaces, and what each can reach

Almost every agent in use today falls into one of three categories. The reach is different for each, and so is the way you contain it.

Browser agents operate with your identity. A browser you’re logged into is a ring of keys — the agent driving it inherits every permission you have, in every tab, with no separate authentication. Told to “reconcile these invoices,” it can reach your accounting portal because you are signed in. What to do: give browser agents their own browser profile with only the sessions the task needs, never run them on a machine logged into privileged systems, and require a human to confirm any irreversible or outbound action — sending, paying, deleting.

Coding agents are the highest-blast-radius category, because a shell is universal reach. An agent that can run commands can read any file the user can, including credentials, and can execute anything — including a malicious dependency it was talked into installing. What to do: run them in a sandbox (a container or VM), not on the machine that holds production access; give them scoped, short-lived tokens rather than admin credentials; keep secrets out of the working tree; review diffs before merge; and never enable auto-approve against a production environment.

MCP connectors are the fastest-moving surface. The Model Context Protocol is a clean standard for giving agents tools — but each server you connect is a grant of access, and a third-party server you installed without reading is a grant to its author too. What to do: keep an inventory of which MCP servers are installed and why, scope each to least privilege, prefer first-party or audited servers over convenient unknowns, and treat adding one with the same seriousness as wiring a new production integration — because that’s what it is.

Why this is sharper for regulated data

Everything in our desktop-app piece about §203 StGB and confidential client data still holds — but agents raise the stakes. A disclosure risk is bad enough when a tool passively sees a client’s information. An agent that can act can move that information out deliberately: send it, upload it, commit it to a public repo. Combine that with prompt injection and you have a path where content the agent merely read causes it to exfiltrate protected data, with your credentials, and no human in the loop.

As before: the specifics of what your professional duty of confidentiality permits belong with your Kammer or your lawyer, not a blog. The engineering point is narrower and certain — an actor with write access to regulated data needs controls and a record, not trust.

The hardening self-check

This is the technical counterpart to the 20-minute check in the first post. It’s a posture, not a project.

1. 01

   Inventory your agent surfaces

   List who runs which agents, and critically, in which mode — read-only, act-with-approval, or fully autonomous with auto-approve. The mode matters more than the brand. An agent nobody knew was in "auto" is the one to find first.

   ⏱ Half a day

2. 02

   Give agents least-privilege identities

   Agents should authenticate as themselves with scoped, short-lived credentials — never share a human admin login or a long-lived root key. Separate identity means you can scope it tightly, rotate it, and see it in the logs.

   ⏱ 1-2 days

3. 03

   Sandbox anything that executes

   Coding agents and command-running tools belong in a container or VM without standing production access, not on the laptop that holds your cloud credentials. The blast radius of a bad step should be a disposable environment, not your estate.

   ⏱ 2-4 days

4. 04

   Keep a human on irreversible actions

   Require explicit approval before an agent sends, deletes, deploys, pays, or transacts. Auto-approve is for reversible, low-stakes steps. The review gate is where a mistaken plan or an injected instruction gets caught.

   ⏱ Ongoing; setup 1-2 days

5. 05

   Audit every connector and MCP server

   For each connected tool, record what it can reach and who wrote it. Remove anything unaudited or unused. A connector you can't explain is a scope you can't defend.

   ⏱ 1 day

6. 06

   Treat untrusted content as hostile

   Don't point an agent with write access at arbitrary web pages, inbound email, or unreviewed files. Assume any content it reads could carry instructions. Separate the reading of untrusted data from the power to act on sensitive systems.

   ⏱ A policy + a habit

7. 07

   Log the actions, not just the chat

   A scrollback buffer is not an audit trail. Capture the tool calls an agent makes — commands run, files touched, records changed — to a durable, searchable store. If you can't reconstruct what an agent did after the fact, you can't answer for it.

   ⏱ Ongoing; the real work

Want this at the level of actual commands and config — browser enterprise policy, settings.json permissions, pinned MCP servers, and a rules card you can screenshot? That’s the agent-guardrails playbook.

The honest limit, again — and it’s wider here

The first post ended on a hard truth: hygiene lowers risk but produces no evidence. With agents that truth is sharper, because the thing you can’t prove is no longer just what was seen — it’s what was done. When an auditor, your Kammer, or an EU AI Act review asks what your systems did with a person’s data, an agent’s answer has to cover the actions it took on its own, and a chat transcript doesn’t.

Closing that gap is an architecture problem, not a settings problem. It’s the same shape as the perimeter in the first post, with one addition: a gateway that doesn’t just control what data crosses the boundary, but mediates and records the actions agents take — every tool call scoped, approved where it must be, and logged. We’ve drawn how that’s built, in plain terms, in the sovereign-AI blueprint.

If you’re rolling agents out faster than you can govern them — which is the normal state right now — a fixed-price Sovereignty Assessment is where to start. You leave with a map of what your agents can reach, a target architecture, and a costed roadmap, yours to keep either way.