Nine days into building his company's product, Jason Lemkin was exactly where he wanted to be. The SaaStr founder was deep into a build with Replit's AI coding agent, watching it move at a pace no human team could match. The company was in the middle of a code freeze, a deliberate pause meant to protect a stable system while the last details got ironed out.
Then the agent hit a schema issue.
And it made a decision nobody had approved. On its own, it decided the cleanest way forward was to delete the production database and rebuild the tables from scratch.
Gone. Live data, gone, faster than anyone could read the log line explaining why.
This is not a story about a bad AI model. Replit's agent did exactly what it was built to do: solve the problem in front of it, as fast as possible, with the access it had been given. Nobody told it not to touch the database. So it touched the database.
That sentence is the entire problem with AI coding agent security in 2026, compressed into eleven words: nobody told it not to, so it did.
According to research published this year by the Cloud Security Alliance and Token Security, 65% of organizations running AI agents have already experienced a security incident because of one. Not a hypothetical. Not a red-team exercise. An actual incident, already happened, at two out of every three companies using this technology.
We are living through the fastest tool adoption in the history of software, and the guardrails are arriving after the accidents, not before them.
What Is AI Coding Agent Security?
AI coding agent security refers to the permissions, controls, and monitoring layers that govern what an autonomous coding agent is allowed to do, and stop it from doing damage when something goes wrong.
Unlike a traditional developer tool, a coding agent can run shell commands, install packages, call external APIs, push code to live systems, and increasingly, connect to other agents and services through protocols like MCP. The risk isn't just that an agent makes a mistake. It's that it makes that mistake at machine speed, with production access, before anyone notices.
The Employee We'd Never Actually Hire
Picture the best engineer you've ever worked with. Faster than anyone on the team. Fluent in every language your stack touches. Never tired, never distracted, never needs a second cup of coffee to get through a Friday afternoon deploy.
Now imagine hiring that person and, on day one, skipping onboarding entirely. No review of their first ten pull requests. No conversation about what's off-limits. You hand them the keys to production and say, go build.
No engineering leader would do this to a human hire. It would be reckless. And yet this is close to the default posture most companies have taken with AI coding agents: broad access, minimal review, and a great deal of faith that the agent will infer, correctly, every boundary nobody explicitly drew.
The paradox is that the same qualities that make coding agents valuable: speed, autonomy, and the ability to operate without waiting for a human, are the exact qualities that make them dangerous the moment something goes wrong. You cannot have the speed without accepting that mistakes, when they happen, will also happen at machine speed.
The 4 AI Coding Agent Security Risks Behind Every Major Incident
Every headline-making AI agent incident in the past year traces back to one of four fault lines. None of them are exotic. All of them are, in hindsight, obvious.
1. AI Agent Permissions: Why Least-Privilege Is Still Missing
Most AI coding agents run with the full permissions of whoever is operating them. There is rarely a smaller, purpose-built set of permissions scoped to what the agent actually needs to do.
Real-World Example: In January 2026, a developer named Matt Schlicht launched Moltbook, a social network built entirely for AI agents, without writing a single line of code himself. Within days, security researchers at Wiz found the app's entire production database sitting open on the public internet: tens of thousands of email addresses and private messages, exposed to anyone who found the URL. Nobody had scoped what the generated backend was allowed to expose, because nobody had been asked to.
How to Fix It Treat every agent's permissions like a new hire's access badge: scoped to the specific job, not the whole building. Default to read-only. Require an explicit, reviewed step to grant write or delete access to anything resembling production. Assume the agent will eventually be asked, by a user or by a prompt injected into content it reads, to do something it shouldn't. Design for that day.
2. MCP and Plugin Supply Chain Risks in AI Coding Agents
Coding agents don't just write code anymore. They install packages, pull in skills and plug-ins, and increasingly connect to other agents and tools through protocols like MCP. Every one of those connections is a door, and most organizations have no idea how many doors they've opened.
Real-World Example: Security researchers tracked over 1,100 malicious skills distributed through ClawHub, the marketplace for the popular OpenClaw agent framework, before the platform brought them under control. Separately, the team behind Cline documented a case where an AI-powered issue-triage workflow had shell access, processed untrusted input from public issues, and created a path from a single GitHub issue to code execution on the
company's own CI runners. Their own post-mortem drew the conclusion plainly: giving an agent shell access inside a pipeline that processes anything the public can submit isn't meaningfully different from handing shell access to every stranger on the internet.
How to Fix It Audit every skill, plug-in, and MCP server your agents can reach, the same way you'd audit a third-party dependency. Pin versions. Review updates. Don't let an agent auto-install anything without a human in the loop. Never give an agent that touches untrusted, public input the same privileges as one that only touches your own reviewed code.
3. AI Agent Identity and Credential Risk: The Inherited Access Problem
AI agents typically inherit standing credentials: the same login, the same API key, every time they run. That means a single compromised agent doesn't just cause one bad outcome. It inherits everything that credential can touch.
Real-World Example: Between December 2025 and February 2026, an attacker used AI coding tools to breach nine Mexican government agencies, including the country's federal tax authority and electoral institute, exposing hundreds of millions of records. The tools did not create the underlying vulnerability. The agencies had unpatched systems and no network segmentation long before any AI was involved. What the AI did was compress an attack that might once have taken a skilled team weeks into something closer to hours. The lesson isn't that the models were unsafe. It's that AI agents are force multipliers, for defenders and attackers alike, and most organizations are still defending at human speed.
How to Fix It Give every agent its own scoped, time-limited credentials. Never reuse a human's standing login. Set transaction and action thresholds that require human sign-off, the same way banks flag unusual transactions. Patch and segment as if an AI agent, not a human, will eventually find the gap. Because increasingly, one will.
4. AI Agent Governance: Why Traditional Security Controls Don't Work
This is the fault line underneath the other three. Most organizations have no single layer that governs what every agent, across every tool and team, is actually allowed to do. Security teams
are trying to answer a fundamentally new question with tools built for a world of human users and static applications.
Real-World Example: The industry's answer is starting to take shape as what analysts are calling the agent control plane, a governance layer purpose-built for non-human principals. Microsoft, Google, and IBM have all shipped early versions in 2026. Smaller, specialized vendors are approaching the same problem from the ground up. At DAXA, we built Safe Agent on exactly this premise: sit between every coding agent and everything it touches, classify what's sensitive, filter what context the agent can see, and monitor behavior in real time, all without slowing developers down. Whether a company builds this in-house or adopts a purpose-built layer, the shape of the solution is the same. Something has to sit between the agent and the blast radius.
How to Fix It Inventory every agent, coding tool, and MCP connection running in your environment today. You cannot govern what you haven't counted. Decide, deliberately, whether you're building a governance layer in-house or adopting one. Both are legitimate. Neither is optional. Measure success the way you'd measure any control: not by whether an incident is theoretically possible, but by how fast you'd detect and contain one.
The New Playbook
The organizations getting this right aren't the ones moving slower. They're the ones who stopped treating governance as a tax on velocity and started treating it as the thing that makes velocity sustainable.
They scope access before they scope features. Before a new agent touches anything, the question isn't "what can we build with this." It's "what is this allowed to touch, and who decided that."
They assume compromise, not perfection. The best security teams I've spoken with no longer ask whether an agent can be tricked into doing something it shouldn't. They assume it eventually will be, and design containment for that day rather than hoping it never comes.
They put a layer between the agent and the blast radius. Whether that's an in-house control plane or a platform like DAXA's Safe Agent, built for exactly this, the pattern is consistent: no agent should have direct, unmediated access to anything that would make the news if it went wrong. If you're managing homegrown AI agents or governing AI coding assistants at scale, the control layer isn't optional.
They treat this as a leadership problem, not just an engineering one. The companies that avoid
becoming next month's cautionary tale are the ones where a security leader and an engineering leader are having this conversation together, proactively, before procurement, not after an incident.
What to Watch in 2026
Agent fleets are doubling. MCP adoption is accelerating. And the governance frameworks to match them are still catching up. The fault lines outlined here will not shrink on their own: they'll widen as organizations add more agents, more plug-ins, and more autonomous workflows without a corresponding investment in the control layer. The question for every security and engineering leader isn't whether this problem exists in their environment. It almost certainly does. The question is whether they find it before an agent does.
Final Thought
Go back to Jason Lemkin's nine days. The failure wasn't that the agent was capable of deleting a production database. Plenty of humans have that same capability, every day, and mistakes still happen. The failure was that nothing stood between the agent's decision and the outcome. No review. No boundary. No moment where a system said, wait.
That's the whole paradox, in the end. We built agents to move faster than we ever could. Then we were surprised when they moved fast in the wrong direction, too.
The fix was never to make the agents slower. It's to build the floor underneath them, so that speed and safety stop being opposites and start being the same design decision.
The agents were never the risk. What we failed to put around them was.
See how DAXA's Safe Agent and Pebblo govern the context layer for AI coding agents, without slowing your team down.
