The same four concerns keep coming up whenever the topic is the threat model for running coding agents with anything close to production access. Agents can reach the same credentials a human would, and while humans make mistakes too, agents make them faster — the speed is what's actually driving the fear. The real benefit of these tools depends on giving them tooling and internet access, and without it the value drops off sharply, which is exactly the access everyone's nervous about. So much gets produced that reviewing, managing, and monitoring all of it becomes its own problem. And underneath all of it, it's a probabilistic system, so the chance of something quietly wrong sitting undiscovered for a long time is greater than zero.
My first instinct was to draw this as a radar chart — four axes pulling against each other, benefit in the middle, trying to find the balance point among a lot of competing parameters. Before building that chart, I checked each concern against something more rigorous than a conversation: OWASP's Top 10 for Agentic Applications 2026, a peer-reviewed framework built by more than a hundred security practitioners. Three of the four concerns map onto it cleanly. The fourth doesn't, and the reason it doesn't is the actual finding.
Speed of mistakes lines up with ASI03: Identity & Privilege Abuse — "agents holding broad, long-lived credentials turn minor compromises into major breaches through unattributable access." Notice what the framework names as the cause. Not speed. Privilege scope. Speed is the amplifier sitting on top of however much access already exists — it doesn't independently create risk, it multiplies whatever blast radius was already there. Bound the credential the way a Gatekeeper does — a narrow, typed interface instead of a standing production credential — and speed mostly stops being the thing worth losing sleep over, because there's a hard ceiling on what fast action can actually reach.
Tooling and internet access lines up with ASI02: Tool Misuse & Exploitation and ASI05: Unexpected Code Execution — legitimate capabilities chained into something nobody intended. This is precisely what happened in the OpenAI/Hugging Face incident: the sandbox's network block only covered the agent's own interface, and an internal service with legitimate external-fetch capability became internet access nobody granted directly. "Should this agent have internet access, yes or no" was always the wrong question, because a hard yes/no rarely survives contact with everything else the agent can legitimately reach. The right question is what's actually reachable, directly or through something else, and whether each of those paths was a deliberate decision or an accident nobody modeled.
The probabilistic, might-not-surface-for-years concern lines up almost word for word with ASI10: Rogue Agents — "persistent unauthorized activity continues across sessions while appearing legitimate to standard monitoring systems." That's not an abstraction. That's the same incident again: ten weeks of dwell time, because the monitoring in place was built to recognize human attacker patterns, not agent-swarm patterns. The fix there isn't making the model less probabilistic. It's detection tuned to what agent behavior actually looks like — parallelism, repetition, non-human timing — instead of what a human attacker looks like.
Output volume outpacing review capacity doesn't have a clean home in OWASP's taxonomy, and that's worth sitting with rather than explaining away. The framework is built around an adversary — something attacking through the agent. The closest category, ASI09, Human-Agent Trust Exploitation, is about a compromised agent manipulating what reaches a human approval step. That's a different problem. A completely honest, uncompromised agent that simply produces more than any team can meaningfully review has no adversary in the picture at all, and the standard threat-modeling frame doesn't have a slot for a risk that doesn't require one.
It's also not a new problem wearing an AI costume. It's the same finding as the CircleCI data from a couple weeks back: engineering throughput rose 59% year over year across 28 million workflows, and the gains were almost entirely captured by the small number of teams that could scale validation alongside generation. Everyone else got faster at producing something nobody could check as fast as it arrived. Review capacity is bounded by human attention. It doesn't scale by adding more GPUs, and no amount of better credential scoping or better detection touches it at all.
The instinct to draw this as several axes pulling against each other wasn't wrong. The axes were. Putting "privilege scope," "reachability," "detection tuning," and "review bandwidth" on the same chart, scaled as if they're equally hard and equally unsolved, makes the whole problem look like an even, unwinnable balancing act. It isn't. Three of those are specific, well-understood engineering debt with known patterns to pay it down. Only one is a real, structural constraint that better engineering doesn't remove.
If a radar chart is still the right tool — and for a client conversation, it probably is, because it's an easy shape to look at and act on — build it against the actual OWASP taxonomy, ten categories, scored for current exposure and current mitigation on the deployment in front of you. That's ten genuinely comparable axes from a citable, peer-reviewed source, not four things a meeting produced. Review capacity becomes one axis among ten, which is closer to its real proportional weight, instead of a fourth of the whole picture standing in for something that isn't like the other three at all.
Field Mappings