Post cover image

August 18, 2026

Strix: The Open-Source AI Hacker That Finds and Fixes Your App and Website Vulnerabilities

Security testing has always had an annoying problem. You can run static analyzers. You can scan dependencies.

By Tattva Tarang

6 min read

You can throw a vulnerability scanner at your application and get a giant report with hundreds of warnings.

But there's a big difference between finding something that looks vulnerable and actually proving that it can be exploited.

That's where Strix gets interesting.

Strix is an open-source AI penetration-testing tool that uses autonomous AI agents to behave more like real security researchers.

Instead of simply saying:

"This endpoint might be vulnerable."

Strix can run your application, interact with it, investigate suspicious behavior, attempt exploitation, and produce a working proof-of-concept.

In other words, it tries to answer the question developers actually care about:

"Can someone really break this?"

And if it finds something, it can help you fix it and verify the fix.

None

What Exactly Is Strix?

Think of Strix as an AI-powered penetration tester.

Traditional security tools usually follow predefined rules.

For example:

Find SQL query
       ↓
Check for suspicious input
       ↓
Report possible SQL injection

The problem is that applications aren't always that predictable.

Modern applications have authentication systems, APIs, background jobs, databases, business logic, third-party services, and complicated user flows.

A real pentester doesn't just run a checklist.

They investigate.

They form hypotheses.

They try things.

They follow unexpected behavior.

Strix attempts to bring that style of testing to an AI agent.

A simplified workflow looks like this:

Your Application
      │
      ▼
 Reconnaissance
      │
      ▼
 AI Security Agents
      │
      ├── Explore endpoints
      ├── Inspect application behavior
      ├── Look for vulnerabilities
      ├── Attempt exploitation
      └── Validate findings
      │
      ▼
 Working Proof-of-Concept
      │
      ▼
 Remediation Guidance
      │
      ▼
 Re-test

That last part matters.

A scanner can tell you that something might be wrong.

An agent can attempt to demonstrate it.

Why AI Pentesting Is Interesting

Imagine you have a simple API:

GET /api/users/123

You might have authentication enabled.

So at first glance, everything looks fine.

But what happens if someone changes:

/api/users/123

to:

/api/users/124

If the server doesn't properly check authorization, another user might be able to access someone else's data.

That's an IDOR (Insecure Direct Object Reference) vulnerability.

A basic scanner might have trouble understanding the application's authorization model.

An AI pentesting agent can potentially reason about the behavior:

Create account A
        ↓
Authenticate as A
        ↓
Request resource belonging to A
        ↓
Change resource ID
        ↓
Request resource belonging to B
        ↓
Compare responses

If the second request succeeds when it shouldn't, you have something much more useful than a warning.

You have evidence.

Getting Started With Strix

Strix is designed to be relatively simple to run.

You'll need:

  • Docker
  • An LLM API key from a supported provider

Supported providers include services such as OpenAI, Anthropic, and Google.

Install it with:

curl -sSL https://strix.ai/install | bash

Then configure your model:

export STRIX_LLM="openai/gpt-5.4"
export LLM_API_KEY="your-api-key"

And run your first scan:

strix --target ./app-directory

That's basically it.

Strix can now start assessing the target.

You Can Scan More Than Local Code

One of the useful parts of Strix is that the target doesn't have to be a local directory.

You can point it at a GitHub repository:

strix --target https://github.com/org/repo

Or test a deployed application:

strix --target https://your-app.com

You can also combine targets.

For example:

strix \
  -t https://github.com/org/app \
  -t https://your-app.com

Now the agent has both the source code and the running application available for its assessment.

That's useful because source code tells you how the application works, while the running application tells you how it actually behaves.

Those two things aren't always the same.

API Security Testing

This is where things get particularly interesting for backend developers.

If you already have an OpenAPI or Swagger specification, you don't necessarily need Strix to discover every endpoint by crawling the application.

Give it the API contract directly.

For example:

strix \
  --target ./openapi.yaml \
  --target https://api.your-app.com

Or with a JSON specification:

strix \
  --target ./openapi.json \
  --target https://api.your-app.com

You can also provide a Postman collection:

strix \
  --target ./collection.postman_collection.json \
  --target https://api.your-app.com

This is useful for applications with hundreds of API endpoints.

Instead of telling the agent:

"Go explore this website."

You're effectively telling it:

"Here is the contract for the API. Now test these endpoints."

Testing Postman Collections Directly

Strix can also work with a Postman collection pulled using its ID.

For example:

export POSTMAN_API_KEY="PMAK-..."
strix --target postman://<collection-uuid>

And if the collection uses an environment:

strix \
  --target "postman://<collection-uuid>?env=<environment-uuid>"

That can make API security testing easier when your existing development workflow already revolves around Postman.

Authenticated Testing

Some vulnerabilities only appear after authentication.

For example:

Unauthenticated user
        ↓
Everything looks fine
Authenticated user
        ↓
Access /admin
        ↓
Authorization bug
        ↓
Sensitive data exposed

Strix supports custom instructions.

For example:

strix \
  --target https://your-app.com \
  --instruction "Perform authenticated testing using credentials: user:pass"

You can also tell it what you want it to focus on:

strix \
  --target api.your-app.com \
  --instruction "Focus on business logic flaws and IDOR vulnerabilities"

For more complicated rules of engagement, you can put the instructions into a file:

strix \
  --target api.your-app.com \
  --instruction-file ./instruction.md

This is a much better approach for serious testing because you can explicitly define things like:

Allowed targets
Excluded endpoints
Test accounts
Testing restrictions
Business logic areas
Production limitations

You don't want an autonomous security agent guessing what it's allowed to attack.

Multi-Agent Pentesting

One of Strix's more interesting capabilities is multi-agent orchestration.

Instead of having one AI agent do everything, you can think of the system as a team of security researchers.

Something like:

Strix
                   │
        ┌──────────┼──────────┐
        ▼          ▼          ▼
   Recon Agent  Web Agent   API Agent
        │          │          │
        ▼          ▼          ▼
   Discovery   Exploitation  Logic
        │          │          │
        └──────────┼──────────┘
                   ▼
              Validation
                   │
                   ▼
             Final Report

This matters because security testing isn't one problem.

You might need to investigate:

Authentication
Authorization
APIs
Injection
Business logic
Configuration
Application behavior
Infrastructure

Different agents can investigate different areas and collaborate on what they discover.

Adding Strix to GitHub Actions

A basic GitHub Actions workflow can look like this:

name: strix-penetration-test
on:
  pull_request:
jobs:
  security-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 0
      - name: Install Strix
        run: curl -sSL https://strix.ai/install | bash
      - name: Run Strix
        env:
          STRIX_LLM: ${{ secrets.STRIX_LLM }}
          LLM_API_KEY: ${{ secrets.LLM_API_KEY }}
        run: strix -n -t ./ --scan-mode quick

Now every pull request can trigger a security assessment.

That's a pretty powerful idea.

A developer opens a PR.

The code changes.

The security agent gets another look.

If it discovers a vulnerability, the pipeline can fail.

Security becomes part of the development loop.

Quick Scans for Pull Requests

You don't necessarily want a huge pentest every time someone changes a README.

Strix has a quick scan mode:

strix \
  -n \
  --target ./ \
  --scan-mode quick

For pull requests, Strix can automatically scope quick reviews to changed files.

You can also explicitly specify the diff base:

strix \
  -n \
  --target ./ \
  --scan-mode quick \
  --scope-mode diff \
  --diff-base origin/main

That makes the security check much more practical for everyday development.

Using Strix From Your AI Coding Agent

Here's another part I find interesting.

Strix isn't only a standalone security tool.

It can also be used by AI coding agents.

For example:

npx skills add usestrix/strix

This installs skills for agents such as Claude Code, Cursor, Codex, and other SKILL.md-compatible coding agents.

The skills cover different parts of the workflow:

penetration-testing-with-strix
        ↓
Run security tests
managed-pentesting-with-strix
        ↓
Use the managed platform
fix-security-vulnerabilities-with-strix
        ↓
Remediate findings + re-scan
ci-security-scanning-with-strix
        ↓
Run security checks in CI

This creates an interesting development loop.

Instead of:

Developer
   ↓
Write code
   ↓
Security team
   ↓
Find vulnerability
   ↓
Developer fixes it
   ↓
Security team tests again

You can potentially get:

AI Coding Agent
      ↓
Write code
      ↓
Strix security test
      ↓
Vulnerability found
      ↓
AI fixes vulnerability
      ↓
Strix re-tests
      ↓
Done

That's much closer to an automated security feedback loop.

Local Models Are Also Possible

You don't necessarily have to send everything to a hosted API.

Strix supports configuring an API base URL:

export LLM_API_BASE="your-api-base-url"

This can be useful with local model infrastructure such as Ollama or LM Studio, depending on your setup and model compatibility.

For example, conceptually:

Strix
  │
  ▼
Local API
  │
  ▼
Local LLM
  │
  ▼
Security reasoning

For teams working with sensitive source code, local inference can be an important consideration.

Of course, the quality of the pentest will depend heavily on the model you're using.

Choosing the Model

The model is effectively the brain behind the security agent.

The recommended options include:

OpenAI
openai/gpt-5.4
Anthropic
anthropic/claude-sonnet-4-6
Google
vertex_ai/gemini-3-pro-preview

You can configure the model through:

export STRIX_LLM="openai/gpt-5.4"

And control reasoning effort:

export STRIX_REASONING_EFFORT="high"

The default reasoning effort is high, while quick scans use medium effort.

For serious security assessments, I'd generally favor stronger reasoning over simply trying to make the scan as cheap as possible.

Finding a real vulnerability is worth more than generating a thousand shallow warnings.

Strix Remembers Your Configuration

You don't have to manually configure everything every time.

Strix stores its CLI configuration here:

~/.strix/cli-config.json

So after your initial setup:

export STRIX_LLM="openai/gpt-5.4"
export LLM_API_KEY="your-api-key"

you can continue using:

strix --target ./app-directory

without repeating the configuration.

You Can Also Use a ChatGPT Subscription

One particularly interesting option is authentication through a ChatGPT subscription.

Instead of using a metered API key:

strix auth login chatgpt

Then configure:

export STRIX_LLM="chatgpt/gpt-5.4"

And run:

strix --target ./app-directory

You can check the current authentication state with:

strix auth status

And remove the login with:

strix auth logout

For developers who already have an eligible ChatGPT subscription, this can make experimentation easier.

Final Thoughts

Strix is an interesting example of where AI security tooling is heading.

It's not just another vulnerability scanner that produces a giant list of things you should probably investigate.

The more ambitious idea is:

Give an AI agent access to your application and let it investigate vulnerabilities the way a real hacker would.

It can perform reconnaissance.

It can test APIs.

It can explore applications.

It can attempt exploitation.

It can validate findings with proofs-of-concept.

And, with the right workflow, it can help fix those findings and verify the fixes.