The first wave of MCP was about reach. Connect the model to everything: the filesystem, the database, the ticketing system, the deploy pipeline, the browser. The pitch was that an agent is only as useful as the tools it can touch, so you handed it a wide ring of keys and watched what it could do. For a demo, that is thrilling. For anything that holds real data or ships real code, it is the setup to a bad afternoon.
What is happening across 2026 is a correction. Teams that ran agents with broad tool access for a few months learned the same lesson in the same order, and the conversation moved. The question stopped being "what can the agent do" and became "what can it reach, can I see what it did, and can I undo it." That is a shift from capability to containment, and it is the right one. Capability was never the hard part. An agent that can call a tool is easy. An agent you can let near production is a design problem.
capability was the easy part
Here is the thing the demos skip. When an agent has a tool, it will use the tool. Not maliciously, usually, and not even wrongly most of the time. But an agent optimizes for finishing the task in front of it, and a broad toolset is a broad set of ways to finish a task you did not quite ask for. Give it write access to the whole repo and a vague instruction, and it will happily refactor three files you did not mention because that was the shortest path to green. Give it the database and it will run the migration it decided was implied. The failure mode is not evil. It is overreach, executed confidently and fast.
You cannot out-prompt this. "Only touch the files I mention" is a request, not a boundary, and a request is the first casualty of a long context. The fix is structural, and it comes down to three old ideas that security people have believed for decades and that we are now rediscovering for agents: least privilege, auditability, and reversibility. None of them are new. What is new is that they now apply to a thing that acts on its own judgment at machine speed, which makes getting them right matter more than it ever did for a script.
least privilege: scope the reach, not the intent
Least privilege is the oldest rule in the book, and it is the one agent setups break first. The instinct with MCP is to expose every tool "just in case," because you do not know in advance which the agent will need. That instinct is exactly backwards. The cost of a missing tool is a failed task and a clear error. The cost of an extra tool is an action you did not want and might not notice.
Scope the reach up front. An agent grooming a backlog does not need deploy rights. An agent writing a feature does not need the production database. Decide what a given agent can touch based on the job it has, not the jobs it might someday have, and make the boundary a property of the connection rather than a line in the prompt. The useful mental model is the one you already use for a new hire: you do not give a first-week engineer root on the prod box because they are probably trustworthy. You give them what the work needs and widen it as trust is earned. An agent has earned nothing. Scope it accordingly.
auditability: a log beats a vibe
The second property is being able to see what happened, exactly, after the fact. A lot of agent tooling fails here in a quiet way. The agent does its work behind a summary, "done, I updated the config and restarted the service," and the summary is all you get. That is a vibe, not a record. When something breaks three days later you have a cheerful paragraph and no idea which of the fourteen things it actually touched.
Predictable, inspectable actions beat a black-box automation mode every time. You want each action the agent took to be a discrete, named operation you can list, read, and replay, not a blur of side effects hidden behind a confident recap. This is worth paying for even when it slows things down, because the whole point of delegation is that you are not watching every step. If you are not watching, the log is the only thing standing between you and a mystery. Design so that every meaningful action an agent takes leaves a trace a person can read, and so that the trace is the same whether a human or an agent initiated it. If the audit path forks depending on who drove, one of those paths is lying to you.
approval gates: a human or an agent, but a gate either way
Some actions should not happen without a yes. Not all of them, or you have rebuilt manual work with extra steps. But the ones that are hard to walk back, merging to main, deleting data, spending money, touching anything a customer sees, should sit behind an explicit checkpoint. The checkpoint is where you move from "the agent did it" to "the agent proposed it and something approved it."
The interesting part is that the approver does not have to be a human. On a mature setup, a second agent with a narrow, adversarial job can review the first agent's work against a standard, and a human handles only the exceptions. What matters is not who holds the gate but that the gate is real: that "send this back" is an operation with teeth, that work genuinely stops until approval, and that approving is a deliberate act rather than a default the system slides past when nobody is looking. A gate that always says yes is not a gate. It is a delay with good PR.
reversibility: the rollback has to actually work
The last property is the one most setups wave at and few deliver. Everyone says "you can always roll it back." Then the agent has already force-pushed, or dropped the column, or the change landed in six places and the undo only knows about four. A rollback that only works when nothing went wrong is not a rollback. It is a story you tell yourself before the incident.
Real reversibility means the risky step is the last step, and until it happens nothing is committed. Let the agent do all the work it wants in a place that does not touch the real thing, a branch, a worktree, a staging copy, and keep the landing as a single gated operation at the end. Then "undo" is not a frantic reconstruction. It is "that branch never merged." The discipline is to make the default state reversible and the irreversible step rare, explicit, and gated, instead of letting irreversible actions happen as an ordinary side effect of the agent doing its job.
what this looks like built in
This is the problem defract has been built around, so take the next part as one concrete implementation rather than the only one. defract runs an MCP server that lets an outside manager agent drive a full task: groom the backlog, start work, approve or send back each implementation phase, inspect diffs, and merge. The containment is in the shape of it. Work happens in parallel git worktrees, so an agent's changes sit off to the side until a gated merge, which is reversibility by construction. Specialist review agents check security and structure before anything lands, which is the approval gate with an adversarial reviewer in it. The MCP path runs the same code as the buttons in the app, so an agent-driven run is as inspectable as a hand-driven one and the audit trail does not fork.
The credential follows the same logic. The MCP secret lives in the OS system keychain, gets read through a dedicated process rather than sprayed across environment variables, and can be rotated. Least privilege applied to the key itself, not just the tools behind it. And because it is local-first, the code and the terminal transcripts stay on your machine, so the audit you care about is one you actually hold.
You do not need any specific tool to take the point. The move worth making this year is to stop asking what your agents can do and start asking what they can reach, what they leave behind, and what you can take back. Least privilege, a real audit trail, gates with teeth, and a rollback that works are not friction on top of agent autonomy. They are the thing that makes autonomy safe enough to use. Build the containment first, and then it will not matter how fast the agent moves, because the blast radius was decided before it started.
defract
a structured lifecycle for your Claude Code agents, drivable by hand or by an agent over MCP, with gated phases and a merge that stays reviewable. free, no caps, no signup.