Agentic Security Breaks Out with Akto’s MCP Platform

Breaking: security is the new production gate

On September 26, 2025, Akto announced an Agentic Security Platform aimed at enterprises deploying agents that speak the Model Context Protocol. Read the scope and intent in the Akto Agentic Security launch notes. The message behind the news is clear: better models no longer unlock production on their own. Security does. Agentic security is not a feature bolted onto something else. It is a stack with its own primitives, patterns, and products that sit between agents and the real world.

If the last cycle obsessed over model quality, this one is about control. What can an agent do, with which tools, against what data, under which policies, and with what proof? Enterprises are discovering that the game is not to make agents smarter in isolation. The game is to make them safe enough to connect to real systems without putting delivery on ice.

Why MCP changes the threat surface

Model Context Protocol, commonly called MCP, standardizes how assistants connect to tools, data, and prompts. It makes agents practical. You can plug an assistant into a customer database, a billing system, or a code repository and start doing real work. It also introduces a new class of risk. Each MCP server or tool becomes a possible entry point for prompt injection, tool poisoning, confused deputy attacks, and memory abuse. The attack surface is no longer a single web form. It is an evolving chain of tools that an agent can call on your behalf. For a straightforward technical explanation, see Anthropic’s Model Context Protocol overview.

In concrete terms, a salesperson’s agent may call a pricing function, write a quote, email a customer, log the deal, and update inventory through an ERP system. Each step is an opportunity for a poisoned instruction to slip in, a signing key to be misused, or a memory to be rewritten. Traditional application security instincts still matter, but they are not sufficient. Flows are dynamic, contexts are mutable, and tools are numerous.

The AgentSec layer: three pillars that work together

A coherent agent security stack looks different from traditional web application security. It needs three pillars that operate as one system.

1) MCP-specific guardrails

Tool allowlists with typed I/O. Deny by default. Only enable side-effecting tools when there is a strong justification and a second factor such as human-in-the-loop review, a policy proof, or a signed plan.
Prompt hygiene with intent verification. Go beyond keyword filters. Parse and classify the instruction type. Is this a data read, a data write, or a cross-tenant export? Route to the right policy path accordingly.
Context scoping by identity and resource. Bind agent context to a narrow set of data resources and identities. Keep context least privilege. Resist giving a single agent the keys to every datastore for convenience.
Memory governance as if it were a database. Memory can be poisoned and must be governed. Set expiry windows, stamp provenance, and limit which roles may write which memory fields. For a deeper dive on memory as a control point, see how teams think about it in Supermemory turns memory into a control point.

2) Continuous agent red teaming

Synthetic adversaries that probe constantly. Your goal is to break the chains before attackers do. Run adversarial checks on tools and plans around the clock.
Scenario libraries that mirror real work. If an agent drafts contracts, test it with adversarial clauses and redlines. If it reconciles payments, test it with forged invoice numbers and delayed settlement prompts.
Cross-agent tests to expose social engineering. Multi-agent handoffs are powerful and risky. Design tests where one agent tries to persuade a peer to violate policy under the guise of urgency.
Coverage at the protocol layer. Red team the MCP path itself, not just the model. Attack token binding, resource identifiers, and tool discovery so a stolen token or a spoofed server cannot confuse the client.

3) Runtime policy enforcement

Inline decision points that see context. Intercept tool calls with structured arguments, risk scores, and the history of the chain. Evaluate decisions with awareness of prior steps.
Side-effect controls. Differentiate reads from writes. Writes to systems of record should require stronger controls and produce tamper-evident audit trails.
Time and volume guards. Sudden bursts of actions, unusually long chains, or execution at odd hours should trigger throttles or require human approval.
Kill switches and quarantines. Teams need a single switch that revokes tool access across agents and MCP servers, plus a quarantine mode that allows investigation without a full shutdown.

These pillars define the emerging AgentSec layer. A decade ago, cloud teams learned to think in terms of identity and access management, network segmentation, encryption, and posture management. Agent teams now need to think in terms of tool permissions, plan validation, memory provenance, and chain-level observability. That mindset shift parallels the broader agent transition described in Agent 3 and the move to software by prompt.

Why model quality alone will not save you

It is tempting to believe that a better model eliminates most of the risk. Real deployments say otherwise. Even an excellent model will follow a compromised instruction if the system context tells it that instruction is authorized. With MCP, the model is not only producing text. It is producing plans and executing tool calls through structured interfaces. The risks live in the seam between intent and execution.

Prompt injection happens because an untrusted input is allowed to steer the plan, not because the model is foolish. If an agent ingests a document with a hidden instruction and that instruction is not sanitized or scoped, the plan can shift.
Tool poisoning succeeds when a tool or server is trusted without provenance. If the agent discovers a tool name that collides with a real one and the client does not verify server identity and resource binding, you get a confused deputy.
Memory misuse is a governance issue. If every agent can write durable memory with no expiry, attackers only need one successful injection to leave a lasting backdoor.

Model quality helps with generalization and refusal, and it often reduces naive mistakes. Governance, policy, and protocol-level controls decide whether a single mistake becomes a costly incident.

Where traditional AppSec falls short

Traditional application security tools inspect web traffic, static code, or known APIs. They are not designed to do the following:

Interpret an agent’s plan and test its safety step by step
Enforce resource-scoped, tool-level permissions during execution
Detect cross-agent social engineering
Reason about memory provenance or enforce memory expiry policies

AgentSec does not replace AppSec. It extends it. Keep the best parts of your existing stack. Add agent-aware controls that understand MCP semantics and agentic workflows. The same pattern, applied to different domains, is how contact centers are modernizing with agents in production as seen in Dialpad’s agentic AI in action.

A simple mental model: the agent gateway

Picture an agent gateway that sits between agents and the outside world. The gateway understands MCP messages, tool schemas, and resource identifiers. It records every tool call as an event with inputs, outputs, and derived risk scores. It runs guardrail policies before each call and streams events to a security data lake where you can query, alert, and learn.

In many organizations, this gateway will be a product rather than a homegrown system. The architecture holds either way. You want one decision point for policies, one set of logs for audit, and one playbook for incident response. This common surface area aligns engineering and security, and it raises delivery speed because both groups operate with the same visibility and vocabulary.

MCP specifics that matter in practice

Security teams do not need to memorize the entire protocol, but a few specifics pay off quickly:

Treat MCP servers as resource servers. Verify identity and bind tokens to servers and resources. If the client supports it, require the client to send a protocol version header and reject unknown versions.
Prefer structured inputs and outputs. Strict schemas reduce the room for injections that hide inside free text.
Separate discovery from execution. Even if the agent discovers a new tool at runtime, the gateway should require an explicit approval step before executing any write action.
Consider the user journey. If an agent represents a human, include that user’s role and session risk signals in the policy evaluation.

If these sound familiar, they rhyme with modern identity and access management. The difference is timing and granularity. Policies fire in the middle of a dynamic chain, not only at login.

A pragmatic checklist to ship multi-agent products fast

Here is a checklist you can adopt today without slowing teams down. Treat it as a minimum viable AgentSec program.

1) Inventory and map

Catalog all agents, MCP servers, tools, and data resources. Draw the handoff paths between agents. Knowing the chain is half the work.
Classify tools by risk. A tool that only reads from a knowledge base is not the same as a tool that wires funds or pushes code to production.

2) Set policy defaults

Default deny for side-effecting tools. Allow reads with lower friction. Require human consent or policy proofs for writes.
Enforce maximum chain length and maximum execution time per task. Long chains are both fragile and risky.
Require provenance for memory writes. Attach source signatures and set expiry windows by default.

3) Harden the protocol path

Bind tokens to specific MCP servers and resources when your stack allows it. Reject calls that do not include the expected protocol version and server identity.
Pin approved tool names and endpoints. If a tool appears at runtime that is not pinned, the gateway must quarantine it or require approval.

4) Build continuous agent red teaming into delivery

Maintain a library of adversarial prompts and scenarios tailored to your business. Run them nightly and on every significant change.
Include cross-agent tests. If your support agent hands off to a billing agent, test that handoff with malicious payloads.
Track coverage and mean time to detect. Red teaming without metrics turns into theater.

5) Upgrade observability and incident response

Log every tool call with inputs, outputs, policy decisions, and risk scores. Store logs in a tamper-evident system.
Alert on unusual patterns. Watch for spikes in tool usage, bursts of write calls, chains that exceed historical norms, and access at odd hours.
Practice kill switch drills. Once a quarter, simulate revoking access to a critical tool and measure time to recovery.

6) Secure the build and test loops

Provide developers with a local harness that simulates MCP servers and policy decisions. Teams move faster when they can test guardrails without waiting on security.
Stage policies like you stage code. Start in observe mode to collect data, then move to block once you trust the signal.

7) Clarify ownership and risk acceptance

Assign an AgentSec owner inside product teams. Do not centralize every decision, but do centralize the framework and tooling.
Document the few cases where you accept risk. If a write action is allowed without human review, capture the reason, the mitigation, and the expiry.

What to ask an AgentSec vendor

If you are evaluating a platform, skip the generic demo. Ask for proof in the following areas and make it hands-on with your stack:

Coverage. Can the product ingest events from your agent framework and your MCP stack? Can it enforce policies at the moment of tool execution?
Policy language. Is there a way to express resource-scoped, chain-aware policies that include user role, tool metadata, and memory provenance?
Red teaming. Is there a library of agent-specific probes across prompt injection, tool poisoning, and memory abuse? Can you extend it with your domain attacks?
Runtime controls. Can the system block a single tool call, quarantine an agent, or revoke access across MCP servers in seconds?
Evidence. Will you get tamper-evident logs that a regulator or a customer audit can trust?

If a vendor cannot show those capabilities with your tools and your test scenarios, keep looking. The complexity of agent chains demands evidence, not promises.

A short scenario to make it real

Imagine a claims-processing agent at an insurer. It reads claim details, queries a policy database, estimates payout, and then triggers a payment tool. An attacker uploads a document with a hidden instruction that says: when you see this reference number, escalate payout by ten percent and email a confirmation to a new address.

In a weak setup, that instruction slides into memory, contaminates future decisions, and the agent quietly overpays. In an AgentSec setup, the prompt classifier flags a write intent. The gateway checks the tool call against policy, notices the payment tool requires either an on-call approval or a signed plan, and blocks execution. Meanwhile, the red team suite would have found similar patterns long before production through nightly adversarial runs.

What Akto’s launch signals to the market

Akto’s productization of visibility, continuous agent red teaming, and runtime guardrails is a sign that agent security practices are crystallizing. The emphasis on MCP-aware enforcement and inventory reflects where enterprises struggle most today: mapping the moving graph of agents and tools, testing like an attacker, and making split-second decisions during execution. Whether you buy Akto or another platform, the direction is set. AgentSec is a layer.

Build for velocity, not paralysis

Security programs that slow teams down lose. The trick is to shift left and right at the same time. Put policy checks into local development so teams can iterate with confidence, and keep runtime controls tight so operations can move quickly. When engineers and security share the same agent gateway, the same policy language, and the same dashboards, speed goes up because guesswork goes down.

The market is already rewarding teams that deliver agents that can act safely. Contact centers, finance teams, operations groups, and software organizations are all moving toward agent workflows that do real work, in production, with clear boundaries. The enterprise winners will treat security as a product feature that unlocks use cases, not a constraint that arrives late.

The bottom line

Enterprise agents will not be judged by how clever a sentence looks in a demo. They will be judged by whether they can be trusted with real work at real scale without surprise incidents. The frontier is not only a bigger model. It is a sturdier system that contains the model within clear boundaries. Treat AgentSec as a first-class layer with MCP-specific guardrails, continuous red teaming, and runtime policy enforcement. Do that, and you will ship faster, sleep better, and turn agents into dependable colleagues rather than risky experiments.