Why the answer to secure agentic development isn't tighter restrictions - it's better developer tooling.
Like almost every software company right now, Legit has gone fully AI-native in development. Our engineers' default tool is no longer just an IDE - it's a command line interface with agents like Claude Code or Cursor. We've been steadily pushing further into autonomous, agentic operations: testing, code review, automated bug fixing. Developers now spend the majority of their day commanding an agent.
That shift forced a question on us as a security team, and we had to answer it for ourselves before we could answer it for our customers: how do you keep this secure without grinding it to a halt?
Two Options, Both Bad
When we first looked at the problem, we saw only two paths.
The first was to heavily restrict developers. Approve every operation. Route new MCP installations through IT or security. Control new skills that are distributed through our marketplace and review every small change.
The second was to let developers move at full speed and accept the risk that something bad eventually happens. Meanwhile, we could see the code being produced was becoming less trustworthy, and that near-miss security incidents were already happening (an agent deleting code “by mistake,” for example).
So we did what you'd expect: we started building internal infrastructure to control it - the same technology we ended up shipping to customers as VibeGuard. And we ran it on ourselves.
Blocking Developers Doesn't Make You Safer. It Makes You Blind.
The first thing we learned running our own product on our own engineers is that a block, on its own, gets you nowhere.
Take secrets. We didn't want developers sharing credentials with AI tools, and for good reason. This is one of the most common pitfalls in agentic development: paste a password or a token into an AI session and it lands in history files on the local disk, it becomes part of the agent's memory, and it can be picked up and reused later - sometimes by a third-party plugin you never evaluated. Frontier models are getting better at refusing this, but there are still plenty of ways to inadvertently leak a credential.
So we built a control that blocks it. And then reality hit: sometimes the agent genuinely needs a token to do the job. It needs to hit an internal service, query a staging database, call an API. That's a legitimate need and our control had no answer for it.
Here's what developers actually did when they got blocked. Some deleted the control. Some complained. And the most dangerous group went looking for workarounds - stuffing keys into places far less safe than where they started, just to get the agent moving again.
That last behavior is the one that should worry every security leader. A blocked developer with an agentic tool doesn't stop; they route around you, and the route they pick is almost always worse than the thing you blocked.
The Golden Path Rule
The rule we landed on is simple: if you don't provide a golden path, AI will find a dangerous one. AI agents are goal-oriented in a way that human developers are not. They pursue the objective you gave them literally, and they don't price in the cost of getting there. They will happily do something harmful or unintended if it moves them toward the goal.
You can't govern that with a wall. You govern it by making the safe path the easiest path. If you want developers to move fast and you want the outcome to be safe, you have to build developer tooling that makes secure behavior the default - not friction that makes it the exception.
That principle is the whole design brief for VibeGuard 2.0.
What We Built Instead
Let the Developer Decide - Don't Just Block
Every time an agent is about to do something dangerous - delete code, alter data in a database, touch a production resource - that is something a human should know about. So instead of silently blocking it, we surface it to the developer and let them decide whether it is intentional.
Running this internally, we've gated hundreds of operations. On a near-daily basis we hear the same thing from our own engineers: thank god that message appeared, because the agent was about to do real, unintended damage that would take us back.
Give Secrets a Safe Door
Rather than leave developers blocked and improvising, we built a mechanism to inject secrets into an AI agent session safely, backed by the OS keychain and environment variables. The developer chooses to share a specific credential, scoped to that session only.
We deliver it through a “secrets” MCP that gives developers a clean way to hand the agent access to sensitive data, without the credential ever landing in a history file or the agent's long-term memory. This became the standard way of sharing sensitive data with agents, and it is now an organizational policy.
Make the Generated Code Secure in the First Place
When you're generating code at this volume, you need the AI tool itself to care about security. We've introduced security skills and security tooling directly into the agent's workflow, so quality and security are enforced at generation time rather than discovered later.
The alternative is ugly and expensive: vulnerabilities flow downstream, and you end up in an endless loop where the agent pushes, the pipeline flags a vulnerability, the agent fixes, and it pushes again. Every one of those cycles costs time and tokens. Shifting left with agents is a real, measurable opportunity. To get there, you need the tooling to safely distribute and enforce security skills at scale.
The Part Security Teams Are Missing: Visibility
There's a second problem, and it's the one that keeps security teams up at night.
Our developers are using a wide and growing set of tools - multiple agents, multiple harnesses, MCPs, skills. In addition, there is an enormous increase in the rate of code change: dozens of pull requests an hour, hundreds of code changes a day.
We used to trust those changes for reasons that no longer hold. We had a strong pipeline to test the app and its security, yes, but we also relied on the fact that our developers were well trained, that humans read the code with their own eyes, and that real care went into building the code. When most all of the code is written by an agent, that assumption quietly disappears. What's left is a hope that the person driving the agent used it safely and used the tooling we gave them - and we had no way to tell whether they did.
This is the other half of what VibeGuard does - and that’s for the security team. It gives us a full picture of what's actually being used across the environment: which skills exist, which MCPs are installed, which models, harnesses, and agents are running. If an employee is operating outside the standard toolset, we can flag it immediately.
As we evolve VibeGuard, we're working toward identifying which code entering our pipeline did not pass through our agentic controls and secure development infrastructure and flagging it so we can go back to whoever shipped it and change how they work. Ultimately there has to be a stronger trust in what changes are pushed into our CI/CD.
Two Takeaways
First: the goal is never to block developers - it's to make them strong and fast, while being secure. Hard controls in the middle of their work don't reduce risk, they relocate it, usually somewhere you can't see.
Second: agentic AI is only useful if it can be trusted, and trust doesn't come from restriction. It comes from governance and visibility - knowing what your agents are doing, and giving developers a safe way to do it.
That's why we built VibeGuard 2.0 as a full desktop app, and not as a plugin. VibeGuard is a fleet of secure agents you can manage. It runs on the endpoint, discovers and connects automatically to coding agents, and interacts with developers to enable them rather than standing in front of them.
Being a full-fledged desktop app is what makes end-to-end coverage possible - complete control for the security team. Full speed for the developers, with built in developer productivity tools that defines the secure path.
We keep on evolving VibeGuard, both for our customers and for our developers, in order to make it the standard security path for agentic dev. We already see tremendous improvement in how fun and fast it is to build with AI while retaining security confidence, governance and visibility.
Want to see how VibeGuard governs AI-generated code in your environment and how it empowers developers to AI-code securely? Contact us for a demo.
Download our new whitepaper.
