Knostic is open-sourcing OpenAnt, our LLM-based vulnerability discovery product, similar to Anthropic's Claude Code Security, but free. It helps defenders proactively find verified security flaws. Stage 1 detects. Stage 2 attacks. What survives is real.
Why open source?
Since Knostic's focus is on protecting agents (not vulnerability research), we're releasing OpenAnt for free. Plus, we like open source.
...And besides, it makes zero sense to compete with Anthropic and OpenAI.
Releasing open source tools for security teams to get visibility into OpenClaw in their environments: openclaw-detect and openclaw-telemetry.
- openclaw-detect:
Shell and PowerShell scripts that detect OpenClaw installations on managed devices.
Checks for CLI binaries, app bundles, config files, gateway services, and Docker artifacts across macOS, Linux, and Windows. Deployable via MDM with docs for Intune, Jamf, JumpCloud, Kandji, and Workspace ONE.
- openclaw-telemetry:
A plugin for OpenClaw that captures tool calls, LLM usage, agent lifecycle, and message events.
Includes sensitive data redaction, tamper-proof hash chains, rate limiting, and log rotation. Outputs to JSONL, with optional CEF/syslog forwarding for SIEM integration (not yet tested).
RAPTOR empowers security research with agentic workflows and automation.
It combines traditional security tools with agentic automation and analysis, deeply understands your code, proves exploitability, and proposes patches.
First use: It generated patches for the FFmpeg Project Zero vulnerabilities.
It's also a PoC showing coding agents are generic, and can be adapted like a "WinAmp skin" for any purpose.
Written by Gadi Evron, Daniel Cuthbert, Thomas Dullien (Halvar Flake), and Michael Bargury.
3-5 minutes on the clock per demonstration, ranging from MCP && auto reverse engineering to writing cyber security songs with AI.
The event last week was incredible, this week's is tomorrow (Thursday).
The system will not catch everything in any way - but what it does catch has no false positives by definition. We're very happy to demonstrate live the value proposition and how alerting is one aspect of what we do.
This is why I'm unsure of the value. And to be clear, by "unsure of the value" I don't mean "unsure whether it has any value." It certainly has value. I'm just not sure how much, as, say, a dollar figure.
"No false positives" is fine marketing, but in practice you aren't replacing anyone's firewalls, endpoint agents, sandboxes, SIEMs, etc. All those false positives will still be there, along with many legitimate detections your system never sees.
If money were no object, then absolutely I'd buy. But given that money is usually a factor, that you're limited to detection, that you're only effective in scenarios where attackers touch your decoy systems, and that you're competing for dollars against products that detect more, detect it sooner, and often prevent it automatically, I don't know.
When you get one alert that you realize isn't false and has the forensic data tied to it, you can use it as a harness against the loads of information from all the other sensors (firewall, endpoints, sandboxes etc) to give you a definitive picture you're certain in.
So two questions, really. First, given We generate one because our decoys are real machines and nothing should run on them except for what we put on them., won't that machine look a little different from the outside, that is, the next machine over in the horizontal network than all the other machines? And thus the attacker would be suspicious?
Secondly, who is to say that the attacking army doesn't have a lab simulating an enterprise environment with one or two of your installs there, learning how to detect/avoid/silently compromise them?
Hi, dean here (Cymmetria CTO). Two great questions:
1. The concept being that from looking at the machine on the network we don't do anything different then regular machines, so the goal is to prevent fingerprinting.
2. If the attacker actually attacks the decoy then we are able to capture what that attack looks like, send it to threat management while it's happening and mitigate. At that point if the attacker has found out it's too late. When Attackers will have our systems installed in his labs he'll have to find some way of identifying our machines without attacking them and that's what we've been developing to prevent.
So I am unclear on the meaning of "attack". Is this more than a series of pings, or an attempt to do a pexec or remote viewing of the event log?
Secondly, if the sensor is placed in a pool of developer machines, does it have to have the whole development environment loaded up, for example, and occasionally do compiles?
"Doing anything different" seems to require close emulation of whatever is going on in the rest of the environment, no?
Further, if he has your machines installed in a controlled lab with properly tied off alarm end points (the things you trigger when you see something odd), what is to prevent an attack analogous to a virus writer having a lab full of each kind of antivirus hammering at his samples?
It seems the challenge for building a static alert system or sensor is that engineering talent from a team larger than yours in some other time zone is going to do the equivalent of sending a drone over your island to see what your radar response looks like. As in if they find the destination of your alerts before tickling your box and compromise that first. Or figure out how to set off an fake alarm or nine.
- What is alerted on (or "attack") is configurable and can range from code being executed (which is the true positive alert) to connecting to ports(which has more noise)
- It needs to look like the machine an attacker will be after when he's looking around on the network and that's much simpler then a whole loaded up environment.
- Yes, the decoys look like an integral part of the network
- It could be within every segment of the network and not in it's own island. But it's true that every security solution depends on it's management interface not being compromised :)
Let's say that an attacking organization fully installs your sensor in their own lab. What is to prevent them from engineering an approach to fully defeat the sensor itself?
Like was said before, you have to attack the decoy to recognize it and that enables catching the attack traffic. Also the mere fact that they recount every single action 10 times over before acting is a huge value in and of itself.
On another note I agree that they will try and we will be constantly remembering that fact :)
How does it work, really? Do you provide a plausible-looking virtualized fake enterprise network that will look like a real thing to outsiders? Or do you put honeypot servers alongside other production servers, running whatever applications are really being used by the company? Do you intend to protect against inside threats as well?
Each decoy is configured to look exactly the way that makes sense for the network it's in. An example is a git server with interesting code or an employees pc that shares files that are crafted to draw attackers to that decoy. The decoys themselves can be placed within the customers network or hosted in the cloud by us.
The real trick is "breadcrumbs" which is specific data/files that you can place on the real machines that directs the attackers towards the decoys.
> "breadcrumbs" which is specific data/files that you can place on the real machines
If the breadcrumbs are realistic then you will end up having employees mistake them for real data, and the employees being mistaken for an attack, no?
If the decoys are realistic then they will have realistic behaviour, for instance, doing an auto update. Now, let's say I'm a malicious actor on the network, and I fake the auto-update server so the patches downloaded are backdoored. Its very hard to detect this attack. Any network has a lot of broadcast traffic between all the nodes - if a decoy doesn't transmit any then it would be a suspicious, and if it does, then its hard work for a decoy to separate the real traffic from a potential attack.
The trick is to make the breadcrumbs the type of data that an attacker is interested in, but a regular user will never be aware of.
For example in windows there is a cache of used credentials along with passwords, it is a known infection spreading technique to read that of an infected machine and use t across the network.
A breadcrumb would put a decoy's credentials in that cache. Thereby never doing any side effect to the user and definitively flag attackers by looking at any usage of those credentials.
Are you also hooking OS APIs or the machine feels almost completely real? I mean, if the attacker can detect that some APIs are hooked they can infer you are using some kind of honeypot.
Why open source? Since Knostic's focus is on protecting agents (not vulnerability research), we're releasing OpenAnt for free. Plus, we like open source. ...And besides, it makes zero sense to compete with Anthropic and OpenAI.
Links: - Project page: https://openant.knostic.ai/
- For technical details, limitations, and token costs, check out this blog post: https://knostic.ai/blog/openant
- To submit your repo for scanning: https://knostic.ai/blog/oss-scan
- Repo: https://github.com/knostic/OpenAnt/