VibeDefend by CybeDefend - The one command line to secure your Cursor and Claude Code
by•
VibeDefend installs on your AI coding agent (Claude Code, Cursor, Windsurf, Copilot, Codex and more) with one command. From then on the agent writes with your business rules, mined from your repo, and your security rules in its context. It scans each diff while the file is still open, and a guard refuses rm -rf, sudo or a read of your secrets before it runs. Scanners check code after the commit, this runs before the line is written. Free plan, no card.
Replies
What if there is a conflict between the security directive and the instruction from the developer to the agent?
Btw, Congratulations Team VibeDefend by CybeDefend ✌️
@aymi_malik Thank you so much, really appreciated! 🙏 Great question. When a developer's instruction contradicts a rule injected into the agent's context, the agent doesn't silently pick a side: it flags the conflict, explains which rule is at stake, and the developer decides.
If the instruction reflects a legitimate change (an outdated rule, for example), that correction can feed a new rule proposal at the end of the session, so your rule base keeps up with the code.
And there are two safety nets on top of that:
The end-of-session scan still checks the code, so if the override introduces a vulnerability, the agent gets the finding and can fix it.
For the most critical actions (rm -rf, secret access, destructive commands...), Action Guards enforce the rule outside the model: there, the security policy always wins.
thanks for the support! help us spread the word on LinkedIn, repost this
Being on the AWS marketplace makes procurement so much easier, smart move 🙃
@kshitij_mishra4 Thanks! We're currently working on our Google Cloud Marketplace and Azure Marketplace listings, precisely to make procurement easier for enterprise teams. Both should be live in the coming weeks. Stay tuned! 😃
appreciate the kind words! let's spread the word on X, repost this
From reading the origin story to the "all the apps I scanned were hackable in five minutes" quote, I was left thinking about how this is probably true of many repositories that I have worked with myself. Since there is no card required, this would be my first place to try it out, without the purchase discussion.
The "88%" figure used by Axel in his discussion post is difficult to comprehend but it seems accurate, as agents act quickly and ignore laws that have not been formally documented.
The Florentin point on the cross-user data leak vulnerability is indeed the true point. Injections will always be detected by all the scanners. No context will ever have "user A should not see user B data" unless someone adds it.
As I went through the review posted by Olivier, what caught my attention was the fact that his criticism about how UI still requires many clicks for manual resolution is actually far more valuable than all the fluff written in the review; this is because he actually uses the software on a daily basis.
A request for securing Cursor and Claude Code is a good sell but how about its ability to work in a repo that has a tangled history? Does it need a clean history to extract relevant patterns or works from Day 1?
@hasnain_shah7 It absolutely works from Day 1, even if the repo history is a bit of a mess.
The miner looks for the most consistent patterns across the codebase. If the history is tangled and contains conflicting logic, it might initially extract some contradictory rules. But that’s exactly why we built the review inbox.
You are never locked in: your team reviews, edits, or rejects these extracted rules before they become permanent guardrails.
Mining rules from the repo worries me a bit on older codebases. I audited one last month where four different places decided who counts as an admin, and they disagreed: two lower cased the email, two didn't. "Most consistent convention" there is a two against two tie, and either winner is a bug.
Does the miner flag contradictions like that for a human, or pick one? I'd rather get the list of disagreements than the rules.
@dalemooney Great example, and exactly why the miner doesn't pick. When implementations contradict each other, like your 2 vs 2 admin check, it flags the contradiction for a human to arbitrate instead of turning either side into a rule. As you said, either winner would be a bug.
So you get the disagreements as disagreements. Once your team settles on the right behavior, it becomes the rule and the agent stops reproducing the inconsistency.
@dalemooney anything @CybeDefend should build/improve/fix from your perspective?
@fmerian one thing: show where each mined rule came from, the files it was seen in. A rule written as a plain sentence is easy to approve without checking, and the evidence is what I'd actually review.
Florentin, flagging it for a human is the behaviour I'd want.
the 88% to 89% jump is the number I'd want more detail on, not because it's small, but because it implies 11% of cases still slip through even with the agent governed at write-time. what does that residual 11% look like in practice, is it mostly novel command patterns your ruleset hasn't seen yet, or edge cases where the agent works around the guard through a legitimate-looking path (like writing to a file that gets executed later instead of running the command directly)?
@galdayan Really sharp question, thanks. One clarification first: the 89% isn't a guard metric. It measures business-rule conformance: with VibeDefend, the agent implemented 57 of 64 graded rule specifics exactly, vs 12% for the bare agent and 13% with a realistic rules file.
The residual 11% is 7 deviations, and none of them is the agent routing around a guard:
4 are rules that were never delivered: a retrieval recall gap when the rule belongs to a different family than the ticket (e.g. a loyalty rule on a refund ticket).
3 were delivered but not implemented to the letter: a mis-arbitrated price edge case, a threshold the agent argued against in writing, and one rule served 13 times that the agent still dropped because the ticket explicitly asked for the opposite. Lesson learned: injection informs, it doesn't enforce.
On guards specifically: 1,769 shell commands checked, 17 refused, including one real attempt to pull a stored credential. The indirect path you describe (writing a script that runs later) is exactly what the AI judgment layer is there for, beyond literal command patterns.
Every case is detailed with its traces here: https://github.com/CybeDefend/vibedefend-xp
@florentin_ledy the "injection informs, it doesn't enforce" line is the real answer here, that one rule served 13 times and still dropped because the ticket asked for the opposite is a much better example than a clean number would've been. the retrieval-recall-gap being 4 of the 7 (rule exists but wrong family gets matched to the ticket) also makes sense as the harder failure mode, that's a search problem more than a security one. is that the piece you're actively working on improving, or is manual review of the miss list just the accepted cost for now since it's a small enough number.
@galdayan It is absolutely a context and search problem.
While we are actively improving the retrieval engine, this is exactly why we allow teams to manually complete and curate the rule corpus. It acts as a centralized, living source of truth to keep all business rules up to date and explicitly documented across the board.
@axel_paulin fair, and honestly "curated by the team" is a reasonable answer for something that's fundamentally a retrieval problem, not every gap needs a model fix. thanks for the detailed numbers throughout this thread, that's rare for a launch day comment section.
Almost had an agent read my .env file before I caught it manually. Guard that stops reading my secrets before it happens would have saved me a very uncomfortable five minutes. Does it work for my cloud credentials file as well as for my local secrets?