AI Security Services: A Buyer RACI for Managed Assessments and Inline Controls

Akto publishes separate pages for agentic security services and its AI security product. That split gives buyers a useful starting point: a managed team can assess architecture beyond one request path, while a product sensor acts only where it is deployed. I want to turn that distinction into a buyer RACI, because a proposal that says coverage is broad but leaves six owner boxes blank creates an expensive handoff problem.

TL;DR

• Buy a managed service when you need human-led scope discovery, an assessment, or consulting across architecture beyond one HTTP route.
• Buy a product when you need repeatable discovery, adversarial testing, or runtime monitoring at a documented deployment point.
• Contract for response timing and evidence handoff separately; a report delivery date is different from a runtime alert or block.
• DeepInspect starts only where authenticated HTTP model traffic is intentionally routed through its policy point.

Services and products perform different work

Akto's Agentic Security Services page groups its offer into red teaming for AI agents, consulting for MCP and agent security, plus agentic risk assessment. Its AI Security page describes product-side discovery, adversarial testing and runtime behavioral monitoring. These are vendor claims, and buyers should test them against the proposed statement of work and deployment diagram.

The service route fits a buyer who lacks a complete inventory or needs human review across agent behavior, MCP use and architecture. The product route fits a team with a defined target that needs a repeatable control at a known sensor. A managed assessor can inspect a local tool or connector design. An inline product acts only on traffic or telemetry it receives.

My view is that buying both without assigning the handoff is worse than buying one well. The service finds an issue, the product team assumes the consultant owns remediation, and the consultant's PDF lands in a folder named Final-v7. A usable operating model names who changes the control and who proves the finding stayed fixed.

The AI security tools list covers the broader category. This page owns the provider and customer division of labor.

Start with the route inventory

The buyer owns the initial map. List each production application, model endpoint, user or agent identity source, and connected tool path. Mark the transport used by every arrow. An authenticated HTTPS call to a model belongs in one row. A local agent command, native SaaS inference path, MCP STDIO call or provider-hosted memory path needs another.

Put the map on one sheet of paper. Draw application boxes in black, model routes in blue and local or native SaaS paths in red. A proposal that shades the whole page blue while the red arrows remain unassigned is incomplete.

The service provider can validate this inventory during discovery. The customer still approves it because only the customer knows which bypasses are tolerated and which data owners authorize testing. Product coverage should then be attached to individual arrows, not to the application name. One application can contain a routed model call, a local tool action and a native connector that never reaches the same control point.

Use the AI security vendor evaluation criteria for product placement questions. For the service contract, require a named owner for every route that falls outside the purchased sensor.

Assign the provider and customer RACI

The RACI needs decisions rather than department labels. The customer is accountable for route inventory, and the provider can validate it. Application and security owners approve test scope; the provider executes only against named targets and identities. The team operating the product owns runtime configuration, with the data owner consulted on classification rules.

Incident response needs a cleaner split. A managed service may identify a finding or help interpret an event. The customer remains accountable for containment across hosts, credentials, model accounts and downstream systems. If the service includes an active response function, the contract must state which actions the provider may take and the approval path for each. Marketing language about continuous protection is too broad for this decision.

NIST's AI RMF Playbook for Govern supports documented responsibilities, review processes, testing, incident response, third-party coverage and risk tolerances. Use those categories to inspect the RACI. Each should have one accountable owner, a defined artifact and a review trigger.

The final ownership list must name native SaaS AI, local agents, MCP tools, model hosting, bypass routes and incident response. Leaving any of those under shared responsibility without a named person is an unresolved control gap.

Contract response timing by event

A service proposal often uses one service-level phrase for several different clocks, so the contract should separate them. An assessment finding has a delivery date. A critical test finding has a notification deadline. A runtime event has a detection and escalation path. A blocked routed request can generate evidence immediately at the control point, while a consultant reviewing an architecture diagram works on a human schedule.

Ask for the start condition of each clock. The clock may begin when the provider detects an event, when an analyst validates it, or when the customer opens a ticket. Those produce very different outcomes. Then name the receiver: SOC queue, application owner, security lead, or executive incident channel.

The acceptance test should use one staged event. Send an approved adversarial request through the documented test route, note the wall-clock time and follow the resulting artifact into the customer's system. A red ticket icon in the SOC queue is more persuasive than a slide claiming rapid response. Record any manual step, because that step sets the true operating speed.

A product can deny a routed request before model forwarding, while the managed service explains the pattern later. Buyers should preserve both timestamps.

Define the evidence handoff

The managed service should state what it delivers for each workstream. A red-team engagement might produce findings, affected routes and retest results. Consulting may deliver a route inventory. Runtime monitoring may emit an event or policy decision record. These artifacts serve different reviewers.

Require stable finding identifiers so the first report connects to the retest. The customer needs the original evidence, the remediation reference and the retest result under the same ID. A screenshot pasted into a slide is fragile. Keep the machine-readable event reference or record locator beside the human explanation, with access controls appropriate to the captured content.

Decide where the authoritative copy lives. If the provider portal is the only location, contract for export timing, retention and access after termination. If the customer system is authoritative, test the transfer during onboarding. The RACI should identify who checks that every critical finding arrived intact.

The AI red teaming controls guide covers recurring test acceptance. In this buying decision, evidence handoff is the bridge between a service engagement and the customer's operating control.

Residual ownership after the engagement

A service can assess local agents, native SaaS usage and MCP architecture beyond an inline gateway's view. The resulting controls still need system owners. Endpoint teams own local commands. SaaS administrators own native configuration. Tool-server owners handle MCP execution according to its transport. Model-hosting teams own the inference environment.

For authenticated model traffic deliberately routed through an HTTP policy point, the gateway team owns deployment and policy availability. Application owners must prevent undocumented direct routes, and identity teams must supply trustworthy caller context. Incident response coordinates evidence from the gateway with logs from endpoints, SaaS platforms and downstream APIs.

A managed provider can remain responsible for scheduled retesting or advisory support. It cannot absorb customer accountability by appearing in every RACI row. That is the opinion I would put into the procurement record: shared responsibility is acceptable only after each decision has one named accountable owner.

DeepInspect

DeepInspect covers a specific slice of this operating model. It evaluates authenticated HTTP model traffic that the customer intentionally routes through its policy point. That route can produce a policy outcome and per-decision evidence for the customer or managed provider to investigate.

Native SaaS inference, local agents, MCP tools outside a routed HTTP path, model hosting and direct bypass routes remain separate responsibilities. A managed service can assess those surfaces and coordinate the broader program. The RACI should preserve that boundary in writing and name the owner of every red arrow on the route map.

Book a demo today.