Strix started as an open-source framework for autonomous security testing.
Today, we're launching the Strix Platform: the product layer around that same framework for teams that want Strix running continuously across their repos, applications, and attack surface.
Since the open-source launch, Strix has grown to 80,000+ users worldwide, 15B+ LLM tokens processed daily, 1,300+ pentests run per day, and 78,000+ vulnerabilities reported.
The community has already been assigned many CVEs found with Strix, and enterprise security teams around the world have made Strix part of their daily workflow.
Vulnerabilities reported
The demand was consistent. Teams wanted the framework, but they also wanted scheduling, state, validation history, auto-fix, integrations, and enterprise controls around it.
Over the past few months, we've been running the platform in beta with early users, enterprise teams, and design partners. Today, we're opening it up more broadly.
Why now
AI changed the throughput of software development. Teams are shipping more code, more APIs, more services, and more infrastructure changes in less time.
Security did not get the same throughput upgrade.
Most workflows still depend on disconnected scanners, periodic pentests, manual triage, and tickets that lose the original context. That works poorly when the system being tested changes every day.
Strix is built for the new pace: run continuously, validate exploitability, keep context attached, and move directly from finding to fix.
Core platform
The platform keeps the full testing loop in one place.
Targets, scopes, runs, findings, exploit evidence, fixes, retests, and integrations all share the same context. A finding from a pentest can become a fix. A fix can be retested against the original exploit path. A recurring run can reuse what Strix already learned from previous runs.
Autonomous pentesting
Strix runs agentic security testing across web apps, APIs, repositories, and exposed services.
The output is not a raw scanner queue. Strix attempts to reproduce issues, captures evidence, and reports what was actually validated: the affected path, the exploit condition, the impact, and the remediation context.
That makes the finding useful to both sides of the workflow. Security can trust it. Engineering can fix it.
Auto-fix
Validated findings already contain the most important context: where the bug is, how it was reached, and what behavior made it exploitable.
Auto-fix uses that context to generate a patch, open a pull request, and retest the vulnerable path after the change. More than just producing advice, the goal is to produce a fix that a developer can review and merge.
Every issue also includes a "Copy AI fix prompt" action. It packages the vulnerability, root cause, exploit context, and suggested fix into a prompt you can give directly to coding agents like Claude Code or Codex.
Retesting
A fix only matters if you can prove the issue is gone.
Strix keeps the original validation context attached to the finding, so teams can rerun the relevant test after a patch and compare the result against the path that failed before. You can also rerun an existing pentest with the same target and scope, or use it as the starting point for a scheduled run.
Security chat
The platform also adds a chat interface around your findings and runs.
You can mention any issue and reason about it with the same context Strix used during the run. Ask it to explain the root cause, go deeper on exploitability, try variants, compare possible fixes, or clarify what should change before you merge.
Continuous coverage
Security should run when the system changes.
The platform can run on schedules, on deploys, on pull requests, when attack surface changes, and when relevant CVEs or new threats appear. Each run adds more state, so Strix can catch regressions and avoid starting from zero every time.
Continuous coverage is the main shift: security validation becomes part of the delivery system instead of a separate event after the fact.
Scheduled pentests
Teams can schedule Strix to run against the same apps, APIs, repos, and domains on a recurring basis.
That turns pentesting into a standing control instead of a manual job someone has to remember to start. Strix keeps the scope, run history, findings, and validation context attached to the target, so each run can surface new issues, confirm fixes, and catch regressions as the system changes.
Analytics dashboard
The new dashboard gives teams a live view of security posture across the organization.
Instead of treating each pentest as an isolated report, Strix shows how risk changes over time: which assets keep producing findings, whether critical issues are getting fixed, where vulnerability classes are clustering, and whether coverage is keeping up with the systems that matter.
That makes Strix useful beyond a single run. Security teams get the trend, not just the latest alert.
Integrations
Strix connects to the tools that already own the work: GitHub, GitLab, Jira, Linear, Slack, and CI/CD pipelines.
Findings show up where teams triage. Fixes show up where developers review code. Alerts show up where incidents and release blockers already get handled.
Get started today
You can start with a repo, a domain, or an application target.
Connect it to Strix, run a pentest, review the validated findings, and generate a fix when the vulnerable path is clear.