Setting up an integration is a build task. Owning its permissions is a judgment task. They are different jobs, and they usually land on the same person by default.
The person who builds it wants it to work. That is a reasonable goal. It also means they reach for the broadest access that gets the demo running, because narrowing it later feels like extra work.
What the builder optimizes for
Take a hypothetical example. An operations lead wants an assistant that drafts replies to internal IT requests. The engineer wiring it up has an admin token handy. It works on the first try, so the token stays.
Nothing is wrong yet. The assistant only drafts, and a person reads every draft. But the token can now do far more than drafting. Nobody decided that. It just happened.
What the owner should decide
The owner of a workflow's permissions is the person who understands what the workflow is for and who answers if it goes wrong. That is often the team lead who uses the output, not the person who wrote the connector.
That owner can answer questions the builder cannot:
- What is the smallest set of things this workflow needs to read?
- Does it ever need to write, or is a draft for review enough?
- Who approves a change to its access?
- Who gets told when access is changed or removed?
A bounded example
Here is a demo scenario, not client work. A team wants a read-only lookup that answers "which vendor owns this contract renewal?" from an internal tracker.
The builder connects it. The owner then reviews one page: which tracker views the credential can see, that it cannot edit anything, and that its use is logged under a name someone recognizes. If the workflow uses MCP, that page also lists which tools the server exposes. If it does not use MCP, the page is just as useful without that line.
That review takes a short meeting, not a program.
Why this still matters outside regulated work
An internal tracker is not a regulated system. It still holds names, prices and plans that people expect to stay inside the company. Lower-risk does not mean no obligations.
The handoff
When the build is done, the builder hands over a short note. It says what the integration can reach, what it cannot, where the credential lives and how to revoke it. The owner reads it, asks questions and signs off in plain words.
If the owner cannot understand the note, the access is too complicated for the workflow.
This is the kind of handoff we review at FusionAL: one workflow, a few useful checks, and a note a non-engineer can follow.
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)