Agents are the new users. Security tooling shouldn't be an exception.
Today we're releasing the Strix API - a full REST interface to Strix, designed so that humans, scripts, and autonomous agents can drive pentests from wherever they already work. Everything the dashboard does is now available over HTTP, with bearer-token auth, organization-scoped permissions, and first-class primitives for pentests, vulnerabilities, schedules, and webhooks.
Everything is documented at docs.app.strix.ai - hand the docs directly to Claude Code, Codex, or any other agent and it can drive the API end-to-end.
Building for agents
Every piece of developer tooling is quietly getting a second class of user. Your CI already calls your test runner without a human clicking through. Your coding agent already runs your linter, your type checker, and your deploy script without supervision. Security tooling has mostly been the exception - still gated behind a dashboard, still assuming a human is doing the driving.
Strix has been autonomous on the inside from day one - a multi-agent system that runs a pentest end-to-end without a human in the loop. But externally, until now, the only way to kick it off was to open a browser. That mismatch was the entire motivation for this release.
The Strix API lets any caller - a Python script, a CI job, a security copilot, Claude Code, or your own in-house agent - do everything the dashboard can do: start a pentest, poll for its status, read findings, trigger a schedule, subscribe to a webhook. Same Strix, headless interface.
What can be done with the API
The API is organized around four primary resources. Pentests cover the full lifecycle of a run - start a new pentest against a domain or repository, list historical runs, get details and findings summaries, rerun a previous configuration, cancel an in-flight scan, and download the PDF report. Vulnerabilities let you query and update findings across every pentest your organization has ever run: list, filter, read individual findings, and update status or notes once something's triaged or remediated. Schedules establish recurring testing against an asset - create, pause, resume, trigger on-demand, or delete. Webhooks deliver lifecycle events (pentest started, pentest completed, new critical finding) to any URL you control, with signed payloads and full delivery inspection for debugging.
Everything is plain HTTP, authenticated with a bearer token against https://app.strix.ai/api/v1. Starting a pentest is a single POST:
| 1 | curl -X POST https://app.strix.ai/api/v1/pentests \ |
| 2 | -H "Authorization: Bearer $STRIX_TOKEN" \ |
| 3 | -H "Content-Type: application/json" \ |
| 4 | -d '{ |
| 5 | "target": "https://api.example.com", |
| 6 | "title": "Pre-release scan of payments API" |
| 7 | }' |
You get back an ID to track. Poll it, subscribe to the pentest.completed webhook, or just come back later - then pull the actual findings:
| 1 | curl "https://app.strix.ai/api/v1/vulnerabilities?scan_id=scan_abc123&severity=critical" \ |
| 2 | -H "Authorization: Bearer $STRIX_TOKEN" |
| 1 | { |
| 2 | "items": [ |
| 3 | { |
| 4 | "id": "vuln_9f2a", |
| 5 | "scan_id": "scan_abc123", |
| 6 | "title": "IDOR in GET /api/users/{id}/invoices", |
| 7 | "severity": "critical", |
| 8 | "status": "open", |
| 9 | "endpoint": "/api/users/{id}/invoices", |
| 10 | "method": "GET", |
| 11 | "description": "Authenticated users can retrieve any other user's invoices by incrementing the path parameter. No ownership check is enforced.", |
| 12 | "cvss": 8.6, |
| 13 | "impact": "Full read access to every customer's billing history." |
| 14 | }, |
| 15 | { |
| 16 | "id": "vuln_2c7d", |
| 17 | "scan_id": "scan_abc123", |
| 18 | "title": "JWT algorithm confusion on /api/auth/verify", |
| 19 | "severity": "critical", |
| 20 | "status": "open", |
| 21 | "endpoint": "/api/auth/verify", |
| 22 | "method": "POST", |
| 23 | "description": "The verifier accepts HS256-signed tokens when the expected algorithm is RS256, letting an attacker forge tokens using the public key as the HMAC secret.", |
| 24 | "cvss": 9.1, |
| 25 | "impact": "Attacker can impersonate any user, including admins." |
| 26 | } |
| 27 | ], |
| 28 | "meta": { "total_items": 2, "has_next": false } |
| 29 | } |
Tokens are organization-scoped with fine-grained permissions - scans:read, vulnerabilities:write, schedules:write, webhooks:read, and so on. Create a separate token per integration, with only the scopes that integration actually needs. This matters more than it used to: when the caller is an autonomous agent, the token is the blast radius.
Best use cases
A few patterns we built the API around.
Orchestrating pentests programmatically. Orgs running Strix across dozens of domains and repositories drive the whole fleet from a single orchestrator - triggering scans, tracking status, rerunning, and pulling reports. What used to be a day of clicking becomes one script.
Findings in your existing stack. Pipe Strix vulnerabilities into Jira, Linear, Slack, or your own AppSec dashboard through the /vulnerabilities endpoints, so findings show up where your team already triages the rest of their work.
Webhook-driven automation. Subscribe to events like pentest.completed or new critical findings and route them into downstream systems - open a ticket, post to Slack, page on-call.
Inside your coding agent. Give Claude Code, Codex, or Cursor the Strix API as a tool. The agent writes the feature, pentests what it shipped, reads findings back, and patches them - all in one session.
Build, pentest, fix, ship
The workflow this unlocks is four steps long: build, pentest, fix, ship. An agent writes code. The API runs a pentest against the result. A coding agent patches what the pentest found. Then it ships. No dashboard, no triage backlog, no human in the critical path for the routine cases - and for the ones that aren't routine, a human reviews a finding that already comes with a reproducible exploit attached.
That loop has been the ambition of every devsecops pitch deck for a decade. The reason it never fully worked is that every step was gated on something slow - a human wading through a SAST queue, a quarterly pentest scheduled out two months, a ticket going stale on a board. When each step in the loop becomes a function call, the loop actually closes.
The Strix API is available today from Settings → API Access inside your Strix dashboard. Full docs at docs.app.strix.ai.