What we still need to verify : 2 points in this profile are not yet confirmed against vendor documentation.
- Current traffic connector list and the open source versus commercial split: confirm
- Scope of AI and MCP specific test coverage: verify against vendor docs
Treat these points as unconfirmed. They are open items in the catalog's verification queue, and this note stays until each is checked against the vendor's documentation.
What it does
Akto works from observed traffic rather than from documentation. You point a traffic source at it, a mirrored VPC session, a Kubernetes daemonset, a gateway log stream, or a proxy capture, and it parses requests into endpoints, infers parameter types from the values it sees, and builds an inventory that reflects what is actually deployed. Sensitive data detection runs over the same stream, tagging endpoints that carry tokens, identifiers or personal data so exposure is attached to a specific route rather than to a service in the abstract.
Testing runs against that inventory. Akto replays requests with mutations to probe for issues that fall out of API design: broken object level authorization, where an identifier is swapped for one belonging to another tenant, broken function level authorization, mass assignment, injection, and rate limiting gaps. Because it has recorded real authenticated traffic, it can replay a request captured under one role using another role's credentials, which is what makes automated authorization testing possible. The same machinery applies to model serving and agent facing endpoints as those join the API estate.
Where it fits
Two placements. In production or staging it sits passively behind a traffic mirror, continuously discovering endpoints and catching shadow APIs that never appeared in a spec. In CI it runs targeted test suites against a deployed environment as a pre release gate. The inventory half is usually owned by security, the test failures land on the owning development team. The prerequisite is access to traffic, which in practice means a networking or platform conversation before any security value appears, plus correctly configured authentication contexts for at least two distinct roles.
Strengths
- Traffic derived inventory finds undocumented and deprecated endpoints that spec driven scanners never see.
- Multi role replay makes broken object level authorization testable automatically, which is the highest value API bug class and the hardest to find by hand.
- Self hosted deployment is available for teams that cannot send request data to a vendor cloud.
- Parameter level sensitive data tagging connects a data exposure finding to the exact route and field.
Limitations
- Coverage is only as good as the traffic you feed it. Endpoints exercised rarely or only by internal jobs stay invisible.
- Authorization testing needs carefully maintained role and token configuration. When that drifts, results turn noisy in both directions.
- Traffic capture at volume carries infrastructure and storage cost, and mirrored production data raises its own handling questions.
Who it suits
Organizations with a large, partly undocumented API estate and enough platform capability to arrange traffic mirroring. A small team with a handful of well specified services will get most of the same value from a spec driven scanner with far less setup.
Used Akto? Recommend it under your own name and title.
Recommend this tool