Akto AI Security Platform: A Route-Coverage Review

Akto presents AI security as a sequence that starts with discovering agents and APIs, continues through adversarial testing, and extends into runtime behavioral monitoring. That sequence is broad enough to sound like one control surface. A buyer still has to trace each capability to the traffic route it sees and the point where it acts. The buyer also needs to know what evidence it retains.

I would evaluate Akto with a route map, not a feature tally. The product claims are useful inputs, but a procurement decision needs proof against the buyer's own agents and applications. It also needs proof against identities and bypass paths.

TL;DR

• Akto says its AI Security product discovers agents and APIs, classifies PII and dependencies, runs more than 4,000 adversarial probes, validates in CI/CD, and monitors runtime behavior.
• Its agentic red-teaming offer covers agents and copilots. It also covers RAG systems and MCP paths, including orchestration attacks and tool misuse.
• Buyers should test discovery and pre-release testing as separate control surfaces. Runtime monitoring needs separate evidence too.
• DeepInspect governs only deliberately routed, authenticated HTTP model traffic; employee devices, native SaaS inference, local agents, and tool execution require other controls.

Akto's published product scope

The Akto AI Security page claims discovery of agents and APIs, classification of PII and dependencies, more than 4,000 adversarial probes, CI/CD validation, and continuous monitoring. Akto also names runtime behaviors such as loops and unauthorized tool calls, plus excessive usage.

That is a substantial scope. Discovery tells a team what exists. Adversarial probes test how a target behaves under selected inputs. CI/CD validation places a test decision before release. Runtime monitoring observes production behavior. Each function can contribute evidence, but they answer different questions and may operate through different integrations.

The right first workshop draws the routes on a wall. Put the employee browser and homegrown application in separate boxes. Do the same for the agent runtime and model endpoint, then add separate boxes for the MCP path and tool target. Then ask Akto to mark which product receives traffic or telemetry at each line. A single platform label should never collapse those paths into one answer.

Discovery needs route-level proof

Akto says it discovers agents and APIs and classifies PII plus dependencies. During evaluation, the buyer should ask how that inventory is produced for each deployment mode. Network observation and code integration create different blind spots. So do cloud metadata, an application connector, and an inline component. The public claim establishes the capability, while the proof of concept establishes its reach inside a specific environment.

I would require one positive and one negative test. The positive test introduces a known application route and checks that the expected agent and API appear. It should also check the dependency and data classification. The negative test creates a direct or unmanaged path and records whether Akto finds it. The second result is more informative because it shows what the discovery method misses.

A discovery record also needs stable ownership. An entry called "chat-service-prod" with no service owner or identity source becomes another dashboard object when it also omits the model destination. The AI security tools list can help separate discovery products from controls that make decisions in the live request path.

Red teaming covers several agent surfaces

Akto's Agentic AI Red Teaming page says it tests agents and copilots. It also says it tests RAG systems and MCP paths. The page also names identity impersonation and orchestration attacks. Tool misuse and data leakage are named too. These are vendor capability statements, so the evaluation should convert them into an agreed target list and retained test evidence.

For an agent, the test scope should name the model route and the available tools. A copilot assessment needs its host application and user roles. RAG testing needs the retrieval component in scope. An MCP path needs the exact server or transport being exercised. These fields keep the result tied to a deployment instead of treating one finding as proof about every agent in the company.

The visual detail I want from the test is mundane: a screenshot with the target URL and test identity visible together. The timestamp and input should also be visible, along with the observed behavior and finding identifier. That single frame is clearer than a thirty-page deck where the target changes names between sections.

CI/CD validation is a release gate

Akto claims CI/CD validation for its adversarial testing. A buyer should determine what causes the pipeline to pass or fail and which test set ran. The buyer should also determine how a later test-set change affects an earlier release. The public page supports the existence of CI/CD validation. It does not settle the buyer's thresholds, branch protections, exception process, or evidence retention.

The acceptance test should run a known passing build and a controlled failing case. The team should then verify the pipeline outcome and the retained report. An exception needs an owner and an expiry date. Without those fields, CI/CD integration can become a report generator that developers learn to ignore.

This control also has a timing boundary. Pre-release validation catches behavior represented in the selected probes and target configuration. Production changes in prompts and models can alter the system after that test. Changes to retrieval data, tools, or identity mappings can do the same. Runtime coverage therefore needs its own proof.

Runtime monitoring needs an enforcement answer

Akto claims continuous monitoring for loops and unauthorized tool calls, plus excessive usage. Those statements establish monitoring scope at a high level. The procurement review should ask what the product observes and when it decides. It should also ask what action follows and which component performs that action.

A finding generated after an unauthorized tool call has forensic value. A pre-execution denial is an enforcement decision. The distinction has operational consequences, so I would ask for a trace of one controlled tool-misuse test with timestamps around observation and action. The same test should show the identity associated with the behavior and the exported event available to the SOC.

Runtime coverage can also differ by path. A homegrown application may expose model calls to an integrated monitor. Native SaaS AI may keep its inference path inside the SaaS provider. A local agent may call tools without sending that action through an HTTP model gateway. Buyers should leave uncovered lines visible on the route map instead of assuming that adjacent telemetry closes them.

Identity and evidence decide the buying fit

The key buyer question is who performed a particular action under which authority. Akto's public pages support discovery and testing claims, plus monitoring claims. The proof of concept should establish how a human or agent identity attaches to each observed route and finding in the buyer's architecture.

Ask for evidence at discovery and the adversarial test. Ask for it again at the CI/CD decision and runtime event. Each record should identify the target and time. It should also preserve the relevant test or behavior plus the disposition. Where a product blocks an action, capture the policy or rule that produced the block. Where it monitors, capture the alert handoff and response owner.

The AI security vendor evaluation criteria provide a broader procurement checklist. My opinion is simpler: reject any demo that cannot replay one request and show exactly where the product first saw it. Architecture diagrams are useful, but the request trace earns the purchase.

The verified product boundaries differ

Akto's published scope spans agent and API discovery and adversarial testing. It also spans CI/CD validation and runtime monitoring. DeepInspect has a narrower route boundary. It applies only when an authenticated user or agent deliberately sends HTTP model traffic through its policy point.

That routed request can receive an identity-aware policy decision before it reaches the LLM, followed by a per-decision audit record. Employee-device traffic outside that route and native SaaS inference remain outside DeepInspect. So do MCP tool execution, local agents, and Akto-managed control-plane functions. The AI firewall, gateway, and proxy comparison explains why product labels cannot substitute for placement in the request path.

The two products could therefore address separate jobs in one program. The buyer still has to prove the overlap and gaps in its own architecture. Public product pages establish claimed capabilities, not an automatic claim that every enterprise route is covered.

DeepInspect

DeepInspect fits the routed HTTP model-call portion of this architecture. It receives authenticated user or agent traffic at a policy point and evaluates identity-bound rules before forwarding permitted requests. It then writes a per-decision record. That role can sit beside discovery and red teaming. It can also sit beside runtime monitoring when those functions cover other layers.

A technical review should start with one production-shaped route and one bypass attempt. The result shows what DeepInspect can govern and what the wider control program must own elsewhere. Book a technical deep dive at deepinspect.ai.