A permissions review that ends in a forty-page spreadsheet usually ends in nothing. People read the first page, agree it matters, and go back to their jobs.
An actionable review is shorter. It names a few fixes, puts them in order and says who does each one.
Start with one workflow
Pick a single bounded workflow. A hypothetical example: an assistant that drafts replies to internal IT requests, and a person reads each draft before it goes out.
Review what that one workflow can reach. Skip the rest of the company. A narrow scope means the findings are specific enough to fix.
What the review should check
For the drafting example, the useful questions are plain:
- Can the assistant only read, or can it also send and edit?
- Whose account does it run under, and what else can that account see?
- Is anything it can reach not needed for drafting replies?
- If the workflow uses MCP, which tools does the server expose, and does the assistant need all of them?
If the workflow does not use MCP, the last question drops out. Not every team needs an MCP audit. Internal, non-regulated work still carries privacy and security duties, so the questions stay.
Turn findings into a fix list
A finding like "access is too broad" gives nobody a task. A fix does.
Compare two versions of the same item:
- Weak: "Service account has excessive permissions."
- Actionable: "Remove write access to the ticket system from the drafting account. Drafts go to a person, so it only needs read."
The second one names the change, the place and the reason. Anyone on the team can pick it up.
Order by what could go wrong
Rank fixes by two things: how much damage the access allows, and how easy the fix is. Removing a write permission nobody uses is a ten-minute change with real effect. Put it first. Redesigning how sessions are issued may matter, but it can wait for a second pass.
I would keep the top of the list to a handful of items. Five fixes that get done beat thirty that do not.
Hand it off in a form people can use
Each item should carry four things: what to change, where, why, and who owns it. Add a way to confirm it worked, such as trying the old action and seeing it fail.
That last step matters. A fix nobody verified is still a guess.
What it looks like in practice
When we review a workflow, the output is this list, not a report about the whole environment. One page. Ordered. Each line ready to assign.
A team can then close the items, rerun the check and see the difference. That is what makes a review worth the time it took.
I'm Jonathan Melton. I run FusionAL, focused on reviewing and integrating lower-risk internal AI workflows, one bounded workflow at a time.
Top comments (0)