The incident you have to explain is the real cost of an over-permissioned agent

Most talk about agent permissions is about what could go wrong. I find it more useful to ask what you will have to say afterwards.

Picture a hypothetical internal workflow. An assistant reads support tickets and drafts a weekly summary for the team lead. It works well. Then someone widens its access "to make it more useful." Now it can read the whole shared drive and send email.

Nothing bad has happened yet. But if something does, you are the one explaining it.

What the explanation looks like

Suppose the summary one week includes a line from a salary spreadsheet. The agent was allowed to read it, so it did. Now you have to answer a few plain questions:

• Why could it see that file?
• Who decided it should?
• How do we know it did not send anything?

If the honest answer to each is "it had access to everything, so we can't say," that is the cost. The time goes into reconstructing events, not into fixing a bug.

A smaller version of the same workflow

Compare it with a narrower setup, also hypothetical. The agent can read one folder of exported tickets. It cannot send anything. It writes a draft, and a person reads it before it goes anywhere.

If a draft looks wrong, the explanation is short. The agent could only see this folder. It could not send. A person approved the final version. You can say that in one breath, and you can prove it from the setup.

Non-regulated still has obligations

Because this is an ordinary internal workflow, it is easy to treat it as low stakes. It still touches people's data and your own internal files. Privacy and security obligations apply whether or not your industry has a rulebook for them.

What I check on one workflow

When we review a single workflow, I look for a handful of things:

1. What can the agent read, and is that the minimum for the job?
2. What can it change or send, and does a person approve that step?
3. If it uses MCP, which tools does it expose, and with whose credentials?
4. Can you reconstruct what it did from a log, without guessing?

That last one matters most. A permission you cannot audit is a permission you cannot defend.

The handoff

The output of this kind of review should be a page the owner can read. It lists what the agent can touch, what it cannot, and where a human decides. If something goes wrong later, that page is the start of your explanation, not a gap in it.

I would rather tighten one workflow properly than loosen ten and hope. Smaller access is easier to explain, and easier to fix.

I'm Jonathan Melton. I run FusionAL, focused on reviewing and integrating lower-risk internal AI workflows, one bounded workflow at a time.