Akto: API and AI Security Testing From Mirrored Traffic

The gap Akto fills: you cannot test APIs you have not enumerated

Most API scanners want a specification. You hand them an OpenAPI file, they fire requests at endpoints, and they report what came back. That works when the spec is accurate and complete. In practice, specs drift, internal endpoints never get documented, and the request shapes that matter (the ones with real object IDs and real session tokens) exist only in production traffic. Akto takes the opposite input. The README describes it as a platform that maintains a continuous inventory of APIs, tests them for vulnerabilities, and finds runtime issues, with the testing engine reading traffic data to understand API traffic patterns. The stated benefit of that reading step is reduced false positives, which is the honest framing: a scanner that knows your actual parameter values and call sequences can tell a real BOLA finding from a 403 that means nothing. The audience is security and engineering teams, and the README names three jobs for them: API inventory, business logic tests in CI/CD, and runtime vulnerability discovery. The repository topics add a second layer aimed at AI systems: LLM security, prompt injection testing, MCP, agentic red teaming, and the OWASP LLM and MCP Top 10 lists. So the project is positioning itself at the intersection of classic API security and the newer surface of agents and model-backed endpoints.

Traffic in, inventory out, tests on top

The pipeline the README sketches has three stages. First, create inventory. Akto ingests traffic from sources it lists explicitly: Burp Suite, AWS, GCP, Postman, and gateways. That ingestion is what produces the API collection, which is the unit the rest of the platform operates on. Second, run tests. The testing engine executes business logic tests derived from the traffic it has seen, which is why the parameter values and call ordering matter. Third, find vulnerabilities in runtime, which the README links to sensitive data discovery in the inventory. The architecture implied by the repository is a Java backend with a separate dashboard container, deployed together through Compose or Helm. The documentation site is the authority on the internal service split; the README itself does not enumerate the containers, so treat any specific service topology you read elsewhere as unverified against this material. What is verifiable is the data flow: traffic source to API collection to test run to finding. Everything in Akto hangs off whether that first arrow is populated. An empty inventory produces an empty test run, and the platform has no way to invent endpoints it has never observed.

Getting it running with docker-compose

The README gives a three-command path for any machine with Docker and curl installed. Clone the repository with `git clone https://github.com/akto-api-security/akto.git`, change into it with `cd akto`, then run `docker-compose up -d`. The dashboard is served on port 9090. That is the whole documented quickstart, and it is deliberately short. The interesting material is in the collapsible section about running it in your own cloud, because the defaults are not safe for a public host. The README is direct about this: open an inbound security rule for port 9090 only, and restrict the source CIDR to your VPC CIDR or your own IP. For a private subnet deployment it recommends an instance with outbound internet access, and gives the tunneling command `ssh -i pemfile ec2-user@vpn-public-instance -L 9090:private-instance:9090`, after which you reach the dashboard at `http://private-instance:9090`. It then says plainly, in its own words, that you should not use an EC2 in a public subnet, and that if you insist, you can reach the instance at `http://ip:9090`. That warning is worth taking literally. A dashboard on port 9090 holds your API inventory, which is a map of your attack surface and, depending on what you ingested, may hold captured request data. For development work the README also documents a VS Code Dev Containers path, with Docker Desktop 2.0+ on macOS, Docker Desktop with the WSL 2 backend on Windows, and Docker CE or EE on Linux.

Where the community edition stops

This is the part most reviews skip, and the README makes it explicit rather than hiding it. The cloud deployment guidance says Akto is powerful in cloud deployment if you can provide your application's mirrored traffic with zero performance impact, and that you would also be able to schedule tests in CI/CD and invite more team members on the dashboard. The next sentence says that for those capabilities you should install the Akto Enterprise edition, linked at stairway.akto.io, with pricing at akto.io/pricing. Read that carefully. CI/CD test scheduling and multi-user dashboard access are described as Enterprise features, even though the README lists running business logic tests in CI/CD as one of the three core things Akto does. The reconciliation is probably that the open repository contains the testing engine and the inventory, while orchestration and team management sit behind the commercial product. The README does not spell out the exact boundary, and that ambiguity is the single most important thing to resolve before committing. If your use case is a solo engineer running tests locally, the gap may never bite. If your use case is a security team of six with a nightly pipeline, you are evaluating a commercial product with an open core, not a fully open platform.

Mirrored traffic is a real prerequisite, not a footnote

The failure mode is structural. Akto's testing quality is a function of the traffic you feed it, and the README's own claim about reducing false positives rests on the engine reading traffic patterns to understand API behaviour. Give it a thin sample and the business logic tests have nothing to reason about. Give it nothing and there is no inventory to test. That means the adoption cost is front-loaded onto traffic capture, which lives outside Akto entirely: a gateway integration, a mirror port, a Burp session, an exported Postman collection. Teams that cannot mirror production traffic, because of compliance constraints, encrypted payloads they cannot terminate, or an architecture where the interesting calls happen between internal services with no tap point, will find Akto's value proposition collapses before they reach the dashboard. The private subnet guidance compounds this. You are expected to run the dashboard somewhere it cannot receive inbound connections, which is correct security practice and also means every developer who wants to look at findings needs VPN or SSH tunneling. That is friction, and it is friction the project has chosen deliberately. There is also a signal in the release cadence: three patch releases on the same day, v2.33.5, v2.33.6 and v2.33.7, all dated 2026-09-10. Frequent patch releases are normal for a fast-moving security product, but they also mean you should pin a version rather than track `master` if you run this in anything resembling production.

Akto against a spec-driven scanner like OWASP ZAP

The natural comparison is OWASP ZAP, which is also free, also open source, and also does API testing. The difference is the input and the resulting test design. ZAP works from a target URL or an imported OpenAPI definition and generates requests from that description of the API. Akto works from observed traffic and generates tests from what the API actually did. In practice that means ZAP can start on day one against a documented API with no traffic capture at all, which is a genuine advantage when you are assessing a third-party API or a service you cannot instrument. Akto cannot do that. Conversely, ZAP has no persistent notion of your API inventory as a living collection, and its findings do not improve because it has seen ten thousand real requests with real object IDs. Akto's business logic tests, the ones that catch BOLA and broken authorization, need exactly that context. Neither tool replaces the other cleanly. If you have traffic, Akto's approach targets a class of bug that spec-driven fuzzing tends to miss. If you do not, ZAP is the tool that will actually run. The README also positions Akto against the OWASP Top 10 and HackerOne Top 10 categories, naming BOLA, authentication, SSRF, XSS and security misconfiguration, so the overlap with any general-purpose scanner is real and you should expect to run one, not both, for the same endpoint set.

Licence, upgrades and the cost of staying current

The repository is MIT licensed, which is permissive: you can use, modify and redistribute the code, including commercially, provided the copyright notice and permission notice are retained. That covers the code in this repository. It does not automatically cover the Enterprise edition, the hosted dashboard, or any container images pulled from Docker Hub, which carry their own terms. The README does not state the licence of the published images, so confirm that separately if you plan to redistribute a bundled deployment. This is a description of the licence text, not legal advice; get counsel if the distinction matters to your organisation. On upgrade cost, the material supports one concrete observation and no more. The project ships frequent patch releases, and the self-hosted path is docker-compose, so upgrading means pulling new images and restarting the stack, with whatever migration the backend performs on its own datastore. The README does not document a migration procedure or a rollback path, and it does not describe a version compatibility matrix between the dashboard and the backend. That absence is the thing to probe before you put this in front of a team that depends on it. The safest posture supported by the material is to pin a specific release tag rather than follow `master`, and to test an upgrade against a copy of your inventory first.

Editorial conclusion

Adopt Akto if you already capture API traffic somewhere (a gateway, a mirror port, Burp, Postman collections) and want an inventory plus OWASP-style test runs without shipping that traffic to a vendor. Do not adopt it if you have no traffic source to feed it, or if you need the CI/CD scheduling and multi-user dashboard features the README places in the Enterprise edition. Verify first that port 9090 is reachable only from your VPC CIDR or your own IP, and that your mirrored traffic actually contains the authenticated requests your business logic tests need.

Official sources

1. akto-api-security/akto on GitHub
2. License: MIT
3. Project website
4. README
5. Releases