Agent security 1 October 2026

Introducing Cyron AI Security: agent boundary protection for MCP and A2A

Cyron AI Security inspects what AI agents send to tools and to other agents, blocks the threat classes you choose and runs fully air-gapped on-premise.

Today we are releasing Cyron AI Security, an on-premise product that sits between your AI agents and the tools and agents they call. It inspects what passes between them, blocks the threat classes you choose, and turns every detection into evidence. It runs fully air-gapped.

The agent boundary: Cyron AI Security sits between your AI agents and the MCP tool servers and A2A agents they call.

Why now: agents act, they no longer only answer

Your API security sees an authorised call. Cyron sees the instruction behind it.

AI agents no longer only answer questions. They call internal tools, read records and message other agents. To a firewall, a gateway or an API security product, that is an authorised application making authorised calls.

The attack is in what the agent was told. A directive hidden in a tool description. A tool that changed after approval. An instruction planted in a tool’s response. A delegation replayed between agents.

Agents reach their tools over the Model Context Protocol (MCP), an open protocol for discovering and calling tools through one interface. They reach each other over the Agent-to-Agent protocol (A2A). The MCP specification was revised in July 2026, and the A2A specification now sits at version 1.0. Both are in production use, and the controls around them are catching up.

The numbers say the same. Gartner reports that 54% of organisations have no defined approach to limiting what AI agents can access. In IBM’s Cost of a Data Breach 2026, more than 20% of organisations reported a breach of their AI models or applications. Compromised APIs, applications or plug-ins were the joint top cause, at 27%.

Cyron AI Security reads the layer those breaches pass through.

What is agent boundary protection?

Agent boundary protection means inspecting the traffic that crosses the line between an AI agent and the tools or agents it uses: the list of tools, each call and each response. It catches attacks that arrive as instructions rather than malformed requests.

That boundary is where Cyron AI Security works. Every tool list, call and response. Every message between agents.

Traffic	What Cyron AI Security does
MCP over Streamable HTTP	Inspects tool lists, tool calls and tool responses, including streamed responses
A2A over JSON-RPC	Inspects messages, tasks and delegations between agents
Malformed or ambiguous messages	Refuses or flags messages crafted to confuse parsers

Take tool poisoning. A tool’s description carries a hidden instruction: read a key file and pass it along. The agent reads descriptions to learn how to use its tools, so it obeys. Every call that follows is authorised and well formed, so a request-level control has nothing to object to. Cyron flags the description itself.

15 detectors in five groups

Each detector looks for one way an agent can be turned against its owner. Each finding carries its class from a public standard: the OWASP Top 10 for LLM Applications (2025) or the OWASP Top 10 for Agentic Applications (2026).

Group	Detector	What it catches	Standard
The integrity of tools	Rug-pull	A tool definition that changes after approval	ASI04
	Tool shadowing	A tool imitating another tool’s name	ASI04
	Weak or poisoned schema	Permissive or unsigned tool schemas	ASI04
	Response-schema divergence	A response that breaks the schema the tool declared	LLM05:2025
Data leaving	Secrets and personal data in tool arguments	Cloud keys, private keys, tokens, card numbers, email addresses, social security numbers	LLM02:2025
	Oversized or encoded arguments	Argument shapes typical of data being smuggled out	LLM02:2025
	Cross-server exfiltration	Data from one tool server reappearing in a call to another	LLM02:2025, ASI04
Injection through tools	Tool-description poisoning	Directives hidden in a tool’s description	LLM01:2025, ASI04
	Hidden instructions	Invisible and look-alike characters, text pushed out of sight	ASI04
	Output poisoning	Instruction-shaped text in a tool’s response	LLM01:2025
Identity	Shared-credential hijack	One credential used across identities	ASI03
	Confused deputy	An agent used beyond its caller’s authority	ASI03
Agent-to-agent traffic	A2A session smuggling	Instructions injected into an agent-to-agent session	ASI07
	A2A delegation replay	Replayed delegations and tokens that never expire	ASI07
	A2A transitive trust	Trust escalated through a chain of agents	ASI07

Detection is deterministic. The same exchange always gets the same verdict, every verdict can be explained, and no GPU is needed. That includes prompt injection where it reaches your agents through the tool layer: directives hidden in tool descriptions and instruction-shaped text in tool responses.

Detect everything, block only what you name

Blocking everything breaks agents. Blocking nothing leaks keys. So you choose the threat classes to block and the severity at which blocking starts. Everything else is allowed and recorded, and blocked calls leave evidence too.

Here is that precision in practice. The test: Cyron AI Security, running as a gateway, set to block one threat class, sensitive-information disclosure, at high severity. We sent five tool calls through it.

Verified result, gateway role: sensitive-information disclosure blocked at high severity

Tool call carrying	Result
AWS access key	Refused. The tool server received it zero times
Email address	Allowed and recorded
14-digit order number	Correctly ignored: it is not a card
Phone number	Allowed
Ordinary text	Allowed

Want personal data blocked too? Lower the severity to medium.

The order number matters as much as the key. It fails the card-number check, so Cyron does not treat it as a card and raises no alarm. An agent that cannot pass an email address to your CRM is useless. An agent that can pass a cloud key to any tool is dangerous. The right control knows the difference, and keeps a record either way.

Evidence classified to OWASP

Every detection becomes evidence an auditor can read.

Durable: findings survive restarts and upgrades.
Classified: every finding carries its class from the OWASP Top 10 for LLM Applications (2025) or the OWASP Top 10 for Agentic Applications (2026).
Honest: a transparent control status report shows exactly what is inspected.
Discreet: credentials seen in traffic are never written to disk.

The refused AWS key above left a finding too, classified LLM02:2025, and the key itself was never written to disk. A blocked call is a record, not a silent drop.

Run Cyron AI Security inside Cyron On-Premise and each finding also arrives as one of seven agent incident types. They sit in the same dashboard and the same SIEM feed as your API incidents, as signed, OCSF-aligned events. Your SOC works agent threats the way it already works API threats.

Two ways to run it

Every capability works on its own. You choose where enforcement happens.

As an MCP gateway. Run Cyron AI Security in front of your MCP and A2A servers. Agents call the gateway, one route per registered tool server, and it refuses a malicious call before the tool is reached. It works on its own or alongside Cyron API Security.

Inside Cyron On-Premise. iris, the eBPF kernel agent, captures agent traffic with no change to your agents. For the threat classes you chose, the source is blocked at the kernel. One sensor, two engines, one enforcement point.

Both roles run self hosted, on a Linux host with a container runtime inside your network. No internet. No call-home. No GPU. The installer verifies checksums, loads images offline and creates its keys on site. New threat definitions and rules arrive as signed, encrypted bundles. Each upgrade backs up your evidence, checks that every finding survived and rolls back if anything fails.

That makes Cyron AI Security a fit for air gapped AI agents in closed and classified networks. Agent-layer analysis reads tool arguments, credentials and internal data in full. That belongs on your own servers, so that is where Cyron AI Security runs. It is licensed by a signed licence file, issued for your deployment, with no call-home.

To follow one attack from capture to block on your own servers, read One sensor, two engines.

What’s next, and how to evaluate it

We are building deeper behavioural insight for every agent, and a direct path from your agent-security evidence into Cyron AI Compliance. Cyron AI Compliance is in development. It will turn that measured evidence into filings for the EU AI Act.

With this launch, two of three products, two-thirds of the platform, are available today. Cyron API Security sees what runs. Cyron AI Security measures what it does. Cyron AI Compliance will prove what happened.

Cyron AI Security is included with Cyron On-Premise and set up in the same install. Whether your agents run on prem in your own data centre or in a private cloud you control, the evaluation happens on your servers. Tell us which MCP servers and agents you run, and we will set it up with you:

We reply with two or three questions about your environment.
A technical call with the people who build the product.
An evaluation on your own servers.

Four steps you can take this week, with or without Cyron

Map the boundary. List every agent, every MCP server it can call and every agent it can delegate to.
Read the tool descriptions in full. Your agents read every word of them, including text a person never sees in a tool picker.
Pin what you approved. Record each tool definition when you approve it, and treat any later change as an incident.
Name your block classes. Decide which threat classes you would refuse outright, and at what severity. Secrets in tool arguments are a good place to start.

Request an on-premise evaluation

Sources

← Back to blog Request an on-premise evaluation