Akto: The API Security Platform That Learns From Your Production Traffic

Hook

Most API security tools test what you tell them exists. Akto discovers shadow APIs you didn't know were running—then automatically generates tests based on how your users actually attack them.

Context

API security has become the weakest link in modern application security. While traditional web application firewalls and security scanners were built for monolithic applications, today's microservices architectures expose dozens or hundreds of APIs that change constantly. The 2023 OWASP API Security Top 10 highlights vulnerabilities like Broken Object Level Authorization (BOLA) and excessive data exposure—flaws that require understanding your API's business logic, not just scanning for SQL injection.

The fundamental problem is visibility. Security teams can't protect APIs they don't know about, and maintaining an accurate API inventory is nearly impossible when developers ship new endpoints daily. Traditional approaches require either analyzing OpenAPI specs (which are often outdated or incomplete) or manual penetration testing (which doesn't scale). Meanwhile, attackers exploit business logic flaws that static analysis tools miss entirely—like changing a user ID in a request to access another user's data. Akto was built to solve this through a radically different approach: passively learn from actual API traffic, build an inventory automatically, and generate context-aware security tests that understand your API's behavior.

Technical Insight

Akto's architecture centers on three components working in concert: traffic collectors, the analysis engine, and the testing framework. The traffic collectors integrate with your existing infrastructure—AWS API Gateway, GCP, Kubernetes, or even Burp Suite—using mirrored traffic that doesn't impact production performance. This is crucial: you're not proxying requests or adding latency. Traffic flows normally while Akto receives a copy for analysis.

The analysis engine is where things get interesting. Rather than simply cataloging endpoints, Akto builds behavioral models. It learns that your /api/users/{id} endpoint returns different fields based on authentication state, that certain parameters are always integers, and that specific headers correlate with admin privileges. This context becomes the foundation for intelligent testing. Here's how you'd configure a custom test that leverages this learned behavior:

id: CUSTOM_BOLA_TEST
info:
  name: "Business Object Authorization with Role Context"
  description: "Tests if user role restrictions are enforced on object access"
  category: "AUTHORIZATION"
  severity: HIGH
  
api_selection_filters:
  response_code:
    gte: 200
    lt: 300
  method:
    contains_either:
      - GET
      - POST
  request_payload:
    for_one:
      key:
        regex: ".*[iI]d$"
        
execute:
  type: single
  requests:
    - req:
      - modify_header:
          Authorization: ${auth_context.regular_user}
      - modify_body_param:
          user_id: ${auth_context.admin_user.id}
          
validate:
  response_code:
    eq: 403
  response_payload:
    not_contains:
      - admin_data
      - sensitive_field

This test definition shows Akto's power: it automatically applies to any endpoint matching the filters, uses learned authentication contexts, and validates both status codes and response content. The auth_context variables are populated from observed traffic patterns—Akto noticed that certain tokens correlate with admin responses and stores them for testing.

The testing engine runs in two modes: passive and active. Passive mode continuously monitors traffic for anomalies without sending any requests—detecting when APIs suddenly expose new sensitive fields or when authentication patterns change. Active mode generates test requests based on the learned patterns. It's smart about this: if Akto observed that your API validates JWTs, it'll test with expired tokens, modified signatures, and algorithm confusion attacks automatically.

The MongoDB backend stores not just test results but the complete traffic patterns over time. This temporal awareness enables tests like "Does this endpoint leak data it didn't expose last week?" or "Did authentication requirements get weaker?" The schema is designed for time-series queries:

{
  "apiCollectionId": 12345,
  "endpoint": "/api/users/{id}",
  "method": "GET",
  "samples": [
    {
      "timestamp": 1704067200,
      "responseFields": ["id", "name", "email"],
      "authLevel": "authenticated",
      "sensitiveData": ["email"]
    },
    {
      "timestamp": 1704153600,
      "responseFields": ["id", "name", "email", "ssn"],
      "authLevel": "authenticated",
      "sensitiveData": ["email", "ssn"]
    }
  ]
}

Notice how the second sample shows an SSN field appeared—Akto would automatically flag this as a new sensitive data exposure and trigger alerts.

For CI/CD integration, Akto provides a testing module that runs against staging environments using the patterns learned from production. You define which test categories to run:

# Run in your CI pipeline
docker run aktosecurity/akto-api-testing \
  --target https://staging-api.company.com \
  --collection-id 12345 \
  --categories "BOLA,SSRF,INJECTION" \
  --fail-on severity:HIGH \
  --auth-token $AUTH_TOKEN

The genius here is that staging tests use production traffic intelligence. If your production API receives requests with 15 different query parameters but your OpenAPI spec only documents 5, Akto tests all 15. This catches the undocumented parameters that often have weaker validation.

The custom test framework deserves attention. You can codify your organization's specific security policies—perhaps you require that any endpoint returning user data must check both JWT validity and a separate rate limit token. Write it once, and Akto applies it automatically to all matching endpoints as they're discovered. This transforms tribal security knowledge into executable, scalable tests.

Gotcha

Akto's traffic-based approach has an inherent chicken-and-egg problem: it can only discover and test APIs that receive traffic. Pre-production APIs or rarely-used administrative endpoints might remain invisible until someone accesses them. If you have strict separation between staging and production traffic, you'll need to run separate Akto instances and won't get production intelligence in your pre-deployment tests. This contrasts with OpenAPI-spec-based tools that can test everything documented, even if unused.

The learning period matters more than the documentation admits. In our testing, Akto needed at least a week of production traffic before generating reliable business logic tests. For a brand new service or one with highly irregular traffic patterns, the initial value is limited—you're essentially back to running generic security tests until the system builds enough context. The 1000+ tests sound impressive, but many require sufficient learned context to be effective. A freshly deployed Akto instance might only run 200-300 relevant tests initially.

Resource usage can surprise you. MongoDB storage grows faster than expected when collecting traffic samples from high-volume APIs. We observed 50GB+ storage for a medium-sized microservices deployment after just two months. The documentation mentions this briefly but doesn't provide clear retention policies or storage planning guidance. You'll need to implement custom cleanup jobs or accept growing infrastructure costs. Additionally, the testing engine is CPU-intensive when running active scans—budget accordingly in your Kubernetes cluster or you'll see resource contention.

Verdict

Use Akto if you have microservices architectures with substantial API traffic (10,000+ requests/day minimum), need continuous security monitoring that adapts as your APIs evolve, or struggle with maintaining accurate API inventories. It's particularly valuable when you have business logic vulnerabilities that static analysis misses—like ensuring user A can never access user B's resources regardless of how they manipulate IDs. The CI/CD integration shines when you can feed production intelligence into staging tests. Skip it if you're securing a handful of well-documented APIs where OpenAPI specs are authoritative and current, need immediate value without a learning period, or lack the infrastructure expertise to operate MongoDB and Java services. Also skip if your APIs are internal-only with no internet exposure and low traffic volume—the pattern learning won't have enough data to be useful, and you'd be better served by spec-driven security testing tools like 42Crunch or traditional scanners like OWASP ZAP for basic vulnerability coverage.