CybeDefend secures the code your AI agent writes, from inside the agent. One command installs VibeDefend on Claude Code, Cursor, Windsurf, Copilot, Codex and other agents. The agent then codes with your business rules, mined from your repo, and your security rules in its context. Each diff is scanned while the file is open, and a guard stops rm -rf, sudo or secret reads before they run. SAST, SCA, secrets, IaC, CI/CD and container scanning are included. Free plan, no card.
This is the 2nd launch from CybeDefend. View more
VibeDefend by CybeDefend
Launched this week
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.
Free Options
Launch Team / Built With
It pleases me that it happens before the command runs and not afterwards. Catching an errant rm -rf before it goes off is precisely what I want my coding agent to do.
CybeDefend
How much control do teams have over the business rules mined from the repo?
CybeDefend
@devinstone Great question! Rules come from two sources, and your team stays in control of both.
At the first scan, our miner analyzes the repo and extracts the most consistent coding conventions and business rules, so the agent starts with a solid corpus from day one.
Then the corpus keeps growing as you code. When a business rule emerges during a session, either because the agent realized it made a mistake or because you corrected it, it can propose that rule at the end of the session. Your rule base gets enriched automatically, session after session.
On the control side:
Session proposals are never applied silently: they land in a review inbox and your team accepts or rejects each one. By default, the agent even asks you in chat before drafting one.
Curious to hear how your team manages these rules today!
CybeDefend
Mastra
@devinstone curious: how do you currently manage your business and security rules with your team?
Does the agent get the security feedback immediately so it can fix the issue in the same coding session?
CybeDefend
@albertnelson Yes! At the end of the session or when he finished part of the deliverable before the pull request, VibeDefend runs a scan on the agent's work. It runs in the background, so the agent can keep going and gets notified as soon as the scan is done, then fixes the findings in the same session.
The scan only covers the files the agent modified, so it's very fast and focused on the work it just did. For example, if it introduces a SQL injection, it gets the finding and switches to a parameterized query before you even commit.
The result: far fewer alerts further down the pipeline.
Mastra
@albertnelson @florentin_ledy related question: how much latency is introduced by these checks?
CybeDefend
@albertnelson One other thing on what that feedback actually contains, because it's where we spend our energy. A SQL injection is the easy part, every scanner catches it. 43% of API vulnerabilities exploit business logic, not a CVE (Wallarm, 2026), and no scanner sees that a refund above 500 euros needs a finance manager.
So the rules are mined from your repo at the first scan, then served to the agent right before it writes the feature the developer asked for, the right rule at the right moment in the right file. We measured the difference on tickets with the same model, and the whole study is public: github.com/CybeDefend/vibedefend-xp. More on why scanners are blind to this: cybedefend.com/en/blog/business-logic-flaws-ai-generated-code
Mastra
@albertnelson thanks for the support! curious what's your stack btw? anything your coding agents did that scared you lately? ping ?makers
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?
CybeDefend
CybeDefend
@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.
CybeDefend
Does the secrets scanner also check files that are generated or modified indirectly by the coding agent?
CybeDefend
@jackthompson68 Yes, in two ways:
Files the agent edits directly are scanned at the end of the session.
If the agent commits during the session, the scan also covers the full git diff of those commits, so files generated or modified indirectly (codegen, scripts, shell commands) are included too.
Upstream, the secret guard also blocks the agent from reading raw secrets (like .env files) and points it to the managed reference instead, so secrets are much less likely to end up in generated code in the first place.
Anything not committed during the session gets picked up by your regular CybeDefend scans (CI or repo) as soon as it lands in the codebase.
CybeDefend
Can teams define their own blocked commands based on their internal security policies?
CybeDefend
@john_michael31 Yes, absolutely! VibeDefend ships with default presets across 5 categories: Filesystem, Shell & commands, Network, Git and Process. They block the most dangerous actions and warn on unusual behavior, which also acts as a safety net if the agent ever gets hijacked (prompt injection, poisoned context...).
From there, everything is configurable:
Switch any preset between warn and block, or disable it entirely.
Create your own blocking rules directly in the VibeDefend tab of your project, to match your internal security policies.
Rules live at the project level, so every AI agent working on that project gets the same policy.
You can cover file reads and writes, deletions, privileged actions like sudo, package installs, destructive Terraform actions, specific processes, git operations, HTTP and network calls, access to specific environment variables, and more.
Happy to walk you through it if you have a specific policy in mind!
Mastra
follow-up question: how do you currently manage security rules with your team?
CybeDefend
@john_michael31 Florentin has the config covered, so a different angle. Blocking rm -rf is the floor, every team should have it and it takes a minute. The part that changed how our users work is that the same project policy carries the business rules too, and every agent on the project gets it, Claude Code, Cursor, Copilot, whichever a developer prefers.
One policy, mined once from the repo, served at the edit. Otherwise you end up with a CLAUDE.md here, a .cursorrules there, and three versions of the truth.. The guards are documented here: docs.cybedefend.com/latest/agent-ai-integration/vibedefend, and if your team runs Claude Code with --dangerously-skip-permissions, this explains what that flag skips and what still blocks: cybedefend.com/en/blog/claude-code-dangerously-skip-permissions-explained
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 ✌️
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.
Mastra
thanks for the support! help us spread the word on LinkedIn, repost this