Skip to main content
An Octopoda scan is a security review done by an AI agent in a private sandbox. The agent reads your code, works out how the app behaves, tries to break it the way an attacker would, and reports an issue in your code only once it has reproduced it.

​
The stages of a scan

Every scan moves through the same stages, and the CLI and the web app show you which one it is in. Step through them below. A scan can end in four ways: See Scans and results for time limits and what each result costs.

​
How a finding is proven

Octopoda only reports what it can show you. There are two kinds of finding, with different evidence:
  • Issues in your code are reproduced in the private sandbox. The agent ran your app and made the attack work, for example by sending a request as one user and getting another user’s data back. The finding shows the steps, and the request and response when there is one.
  • Vulnerable dependencies are packages your project installs at a version covered by a published security advisory (a CVE). The evidence is the advisory and the installed version, not a reproduction, and the finding names the CVE. Octopoda reports these even when it could not confirm that your code uses the affected part of the package, because that cannot be ruled out safely.
Issues in your code that the agent suspects but cannot reproduce are not reported. This keeps your list short and believable, but it also means a scan with no findings is not a guarantee that your app is secure.

​
What Octopoda looks for

The agent has specific guidance for these kinds of issue:
  • Access control: one user reaching another user’s records (IDOR), actions that are missing an authorization check, and mass assignment of fields a user should not set.
  • Authentication: flaws in sign-in, sessions and JSON Web Tokens, and weak passwords.
  • Injection: SQL and NoSQL injection, command and argument injection, server-side template injection, and header injection.
  • Browser attacks: cross-site scripting (XSS), cross-site request forgery (CSRF), open redirects and prototype pollution.
  • Server-side attacks: server-side request forgery (SSRF), path traversal and file inclusion, insecure file uploads, insecure deserialization, XML external entities (XXE) and remote code execution.
  • Logic and timing: business logic flaws and race conditions.
  • Data exposure: information disclosure, such as error pages or responses that reveal more than they should.
  • Dependencies: packages installed at a version with a published CVE.
  • AI features: prompt injection in features built on large language models.
It also has guidance for frameworks and services that AI-built apps often use, including Next.js, Django, FastAPI, NestJS, Supabase, Firebase and Auth0.

​
What Octopoda does not do

  • Octopoda tests the code you give it, inside its own sandbox. It never sends requests to your deployed app, your servers or anyone else’s systems.
  • It does not replace a full manual security audit for high-risk systems.