Most security teams are being handed the same two options for AI coding agents: ban them, or let them run. It gets framed as a maturity question, as though the careful teams ban and the bold teams allow. It is actually a false choice, and both answers are already costing something.
A ban does not remove the agents. It moves them onto personal laptops and side projects where you have no visibility at all. A free pass does a different kind of damage: it hands an improvising process every credential a developer holds, from the .pgpass file to the cloud CLI profile to the long-lived token sitting in a dotfile.
Both choices share a hidden assumption, and that assumption is the real problem. They both assume the only place to put a control is inside the agent: a system prompt, an approval dialog, a rule the model is asked to respect. In April 2026, a startup founder reported that a coding agent deleted the company's production database and its volume-level backups in nine seconds. The agent had been working on a routine task. It found a credential, decided to use it, and acted. No prompt stopped it.
The useful question is not whether to allow agents. It is where the controls live.
The two answers security teams reach for
The ban is the reflex of a team that has read the incident reports and decided the safest move is no move. It feels responsible. On paper, exposure goes to zero.
It does not go to zero in practice. Developers who have felt what an agent does to their throughput do not give it up because a policy says to. They run it on a personal machine, through a personal account, on a copy of the repository you cannot see. The capability you banned is now running with no logging, no scoping and no way to answer a single question after the fact. You have not removed the risk. You have removed your view of it. Microsoft's 2024 Work Trend Index found that 78% of people already using AI at work bring their own tools to do it, which is the shadow a ban creates rather than removes.
"Let it run" is the opposite reflex, and it feels bold rather than reckless because the agent is usually helpful. The cost is quieter. A coding agent authenticates as the developer who launched it, which means it inherits that developer's reach: the database roles, the cloud profiles, the registry tokens, the SSH keys. Most of that access is far wider than the task in front of it. The agent does not need to be malicious to cause harm. It only needs to be confident and wrong while holding a credential it never should have been able to reach.
The trade-off assumes control lives inside the agent
Here is the assumption both answers make: that you can govern an agent by telling it what not to do.
OpenAI published a misalignment report this year describing an internal model that, while exposing a GitHub token in a public repository, was instructed to stop and returned to the workaround anyway. A model that can be told twice to stop and then continue is not a model you can secure with a sentence. System prompts, approval dialogs and "the agent promised to only read" are all the same category of thing: a hint. A hint is useful for steering behavior. It is not a control, because a control is something the agent cannot talk its way around.
Once you accept that the inside of the agent is not a place you can enforce anything, the binary collapses. Banning and allowing are both bets on the agent's cooperation. The third option is to stop betting on it.
Move the controls outside the agent
Put enforcement in the environment the agent runs in, not in the agent, and four things become true at once. These are the outcomes a security leader should be able to demand:
The agent never holds the keys. Credentials live outside the agent's process, environment, files and logs, and are presented to the declared destination at the moment of use. The agent authenticates without ever possessing the secret, so there is nothing in its reach to leak, print or misuse.
Actions are judged by verb and target, not just destination. Reaching the production database is not the same action as dropping a table in it. A control that only asks "which host?" misses the difference. A control that asks "which verb, against which target?" does not.
Every move leaves a receipt you own. Each request, allowed or denied, is recorded to storage you control, tied to the session and the person or trigger behind it. When something goes wrong, the question "what did it send, and where?" has an answer that does not live in a vendor's dashboard.
Developers keep full speed. The controls sit around the work, not in front of every keystroke, so the person using the agent is not clicking "allow" forty times an hour.
None of these is a prompt. None of them depends on the agent choosing to behave.
What this means for the developer experience
Security leaders sometimes treat developer experience as the thing they trade away for safety. With agents, that trade backfires directly.
The most common agent control in the wild is the per-action approval prompt. It works until it becomes constant, and then it becomes reflexive: the developer stops reading and starts clicking through, or turns approvals off entirely. A control that trains people to ignore it is worse than no control, because it also produces a false sense of oversight.
The controls that survive contact with a real team are the ones the developer does not have to think about. A workspace that behaves like a local machine, with the ports and files where they expect them, where the guardrails are simply part of the environment rather than a dialog in the way. Speed is not the reward for weakening security here. It is the thing that keeps the security in place, because a control nobody fights is a control that stays on.
A decision framework for the next 90 days
Before choosing ban, allow or govern, a team should be able to answer three questions with evidence rather than intentions:
- Where do credentials live? If the answer is "in the developer's environment, which the agent inherits," neither banning nor allowing fixes it. The credential has to move out of the agent's reach.
- Who can see what left? If an agent made an outbound request to a destination you did not expect, could you find it, and is that record in storage you own?
- Can you stop one session without stopping everyone? Containment that means pulling the plug on the whole team is not containment anyone will use at 3am.
If you cannot answer these yet, that is the work, and it is the same work whether your current policy is a ban or a shrug. The binary was never the decision. The decision is where you put the enforcement.
Ban it or let it run assumes the control has to live inside the agent. It does not. Move credentials, action policy and audit outside the agent, into the environment it runs in, and you stop having to choose between the speed that made developers adopt agents and the oversight your auditors are going to ask for. Solving the choice is not picking a side. It is refusing the premise.
Another article in this series looks at the first of those four outcomes up close: why secret scanning will not save you, and what keeping the credential out of the agent actually means →
Marshal lets coding agents run at full speed inside your own VPC, with credentials they never see, actions judged by verb and target, and receipts you own. Book a demo →