An MCP connection is bounded twice and approved once — and the approval is your prompt. Design for that before regulated data flows through it.
In a connected-agent walkthrough making the rounds this month, someone asked an agent to close out a task in Linear. It marked the task done the instant it was asked — ticket NAT-2391, no separate confirmation screen, no "are you sure," the write just happened. As reported, that was the whole interaction: a sentence in, a state change out.
Everyone watching that clip saw a productivity feature. I run information security and DevOps for a fintech that serves more than 1,500 financial institutions, and my team built our own governed agent platform — AgentOS — largely to get this exact boundary right, so I watched the same clip and saw a missing control. The write was correct. That is not the point. Nothing sat between the decision to act and the action.
The loud question about connected agents right now is "what can it do?" — which tools, which integrations, how much reach. That is the wrong question. The reach is bounded, and bounded in ways most people never count. The durable question is quieter: when the agent changed something that matters, who approved it? In a connected-agent world the answer is usually your prompt. And nobody governed that one.
Two limits bound the connection. Count them both.
Start with what an MCP connector actually is, using the framing the tool builders themselves use: it is a menu relationship. The product publishes a menu of allowed actions, and the agent can only order from it. It cannot invent a verb the vendor never exposed. That is a real, and reassuring, first limit.
Here is the second limit almost everyone forgets. The agent's reach is also bounded by the permissions of the account or workspace you connected it to, because it inherits that principal's scope. Connect it to an admin's workspace and it can touch everything the admin can. Two limits — and they multiply, not add.
Translate that into the lens a regulated shop already lives in and it is not new at all. This is the same two-tier bound I enforce for every non-human identity: the vendor's published action surface, and the least-privilege scope of the service account the agent borrows. Neither tier is the control by itself. The intersection is. Non-human identities already outnumber humans by roughly 45 to 1, as high as 144 to 1 in some estimates (Cloud Security Alliance, May 2026), and each connector is one more of them.
So the posture is not a preference. Read-only by default, the narrowest workspace that does the job, and explicit scoped write requests are governance controls, not developer conveniences. The default an engineer picks in an afternoon is the blast-radius decision an examiner asks about a year later.
The approval screen you didn't see is the control you didn't build
Here is the mechanic the Linear clip actually exposes, stated plainly: some tools, Codex among them, may not surface a separate approval screen for a write action. There is no second gate between deciding to act and acting. The prompt is the approval, and it is the only approval.
Sit with the demo as the exhibit, hedged as the external account it is. The agent marked the task done immediately — no confirmation, no diff to review, no pause. The write was correct and it was instant. Correct-and-instant is precisely the failure mode you fear when the actor is confused or hijacked, which is the same shape as the widely circulated account of a coding agent that deleted a production database and its backups in about nine seconds. The exact details hardly matter here: speed is not your friend when the thing moving fast has been misled.
I have a vocabulary for this moment. It is where intent becomes effect with nothing in between. In a governed agent the pattern is agent proposes, judge disposes, tool executes — three roles, deliberately separated. When the prompt is the approval, two of those roles collapse into the first one. The thing that decides and the thing that authorizes are the same sentence.
Name it precisely, because the naming is what makes it board-reportable: write-without-approval is a control-plane gap, not a UX quirk. The fix is not a nicer dialog box the vendor might ship someday. It is a boundary you insert yourself.
If the tool won't gate the write, gate it yourself
When a connector executes without an approval screen, you do not get to wait for the vendor to add one. You build the gate around it. Three moves cover most of the exposure, and none of them requires anything the vendor has to ship first.
- Put a human at send, publish, delete, and batch. Require human-in-the-loop specifically for the irreversible and externally-visible verbs, and use reversibility as the gate exactly as you would on a graduated-autonomy ladder. Marking one ticket done is cheap to undo; emailing a customer, publishing a page, deleting a record, or running one action across a hundred rows is not. Match the gate to the cost of being wrong, not to how good the demo looked.
- Make every write request narrow and explicit. Scope each write to a named record, a named recipient, a single action. Never "clean up my board" — always "mark
NAT-2391done and nothing else." A broad write request handed to a tool with no approval screen is a loaded prompt, and the breadth of the instruction becomes the breadth of the blast radius. - Inspect externally-authored content before it enters the context. Partner feeds, ticket bodies, comment threads, shared docs — anything the connector pulls in that a human outside your trust boundary wrote — is untrusted input. Combine it with private data and the ability to act, and you have assembled the lethal trifecta by pure convenience. This is not a fringe risk: OWASP mapped prompt injection into six of the ten categories in its agentic-AI Top 10 (June 11, 2026). The input side is structural, not incidental.
None of this replaces the control plane you already run; it extends it. A connector is just a new tool surface, so the same layered controls apply — scoped tools, a judge at the action boundary, run-level attribution. The MCP-specific move is only this: refuse to let the vendor's missing approval screen become your missing approval.
Retrieval breadth is a cost control and an exfiltration surface at once
Now the part almost nobody governs, because it hides inside a helpful behavior. The cost of a connector does not scale with the connection existing; it scales with how much you retrieve through it. One pending task returns a small record. "Summarize everything I did last quarter" pulls ninety days of history into the context window and bills you for all of it. The connection is nearly free. The pull is where the meter runs.
Treat that as query governance. Narrowing a prompt by project, date, person, or record is the token-spend equivalent of putting a filter on a database query. An unbounded "pull everything and figure it out" prompt is the agent-era SELECT *, and it costs like one.
Here is why a security leader cares about a FinOps detail. The same breath does double duty: the wide read that runs up the bill is also the read that stages data for exfiltration. A history dump is simultaneously a FinOps event and a DLP event — one behavior, two controls — and you can catch both by governing scope at the prompt. Narrow the query and you have bounded the spend and the leak in the same move.
The obligation underneath is over-collection. An unbounded pull across a connected workspace can sweep in member PII or regulated records the task never needed, and over-collection is precisely what an examiner and a data map both punish. I will not put a dollar figure on it, because the honest one is a range — but the direction is not in doubt: the pull you did not scope is the pull you will have to explain.
Inventory what each connection can read versus change. Then decommission it.
Every connected agent needs a documented, per-connection inventory of what it can read versus what it can change. "The agent has Slack and Drive" is not an entry. "This connection can read channels X and Y and post only to Z, under service account A, owned by human B" is an entry. The difference between those two sentences is the difference between an audit you pass and one you improvise.
Then add the step everyone skips: decommissioning. Connectors accumulate silently. Nobody removes them, because nothing breaks when they stay. But an unused connection is standing authority with no owner watching it — the machine equivalent of a departed employee whose badge still opens the door. Bake a disconnect-when-idle step into the connector lifecycle the same way you offboard a person's access.
You do not need a program to start. A four-question checklist before you connect anything, and a short security-judgment pass before a new connector goes live, is enough of a ritual to keep this from sprawling. Governance here is a habit, not a gate.
And the inventory is not paperwork you write after the fact. It is the log the examiner asks for the moment they see an agent touching regulated data — the artifact a SOC 2 reviewer or a Treasury-aligned examination requests by name, against the kind of control objectives the US Treasury's Financial Services AI Risk Management Framework (February 2026) spells out for AI that touches regulated financial systems. You either generate that record as a byproduct of how you connect, or you reconstruct it under duress. For a company answerable to more than 1,500 financial institutions, "we'll reconstruct it" is not an answer I get to give.
Set these six defaults before the next connector goes live
You do not have to wait for a single vendor to close this. Default every new MCP connection to read-only in the narrowest workspace that does the job. Require write requests that name one record and one action. Put a human at send, publish, delete, and batch. Inspect anything externally-authored before it enters the context. Scope every retrieval by project, date, person, or record — the tight query is the cheap query and the safe one. And keep a per-connection inventory of read versus change, with a decommission step for anything idle.
The connectors are outrunning the controls this quarter. That is the whole risk in one sentence. Name the two tiers that bound the connection, insert the approval the vendor left out, and you keep regulated data on the right side of a boundary you actually own — instead of on the right side of one you were lucky about.
For anyone already running MCP connectors into Slack, Linear, Drive, or a repository in a regulated environment: where did the missing approval screen bite you first, and what did you wire in front of it? Tell me in the comments — that is the part the walkthroughs never show.
