1. Inspect
Tool lists, calls and responses over MCP, and messages between agents over A2A, pass 15 detectors.
Available · On-Premise
Cyron AI Security
Agent boundary protection for MCP and A2A
Cyron AI Security answers the question auditors have started to ask: what did your AI agents send to their tools, and what stopped them when it mattered? It inspects the exchanges between your agents and the tools and agents they call, blocks the threat classes you choose, and keeps evidence for every detection, entirely inside your own infrastructure.
The gap
Your controls see an authorised app making authorised calls.
Enterprises are moving from AI that answers questions to AI that takes actions: calling internal tools, reading customer records, writing to systems and sending data outward. The controls that protect networks and APIs do not observe this layer.
What they cannot see is that the instruction to make those calls arrived inside a poisoned document, a manipulated tool description, or a compromised agent-to-agent message. Meanwhile auditors, regulators and boards are asking organisations to demonstrate that their AI systems are robust against manipulation. Article 15 of the EU AI Act will require high-risk AI systems to achieve an appropriate level of accuracy, robustness and cybersecurity throughout their lifecycle, with technical measures that address, where appropriate, data and model poisoning, adversarial inputs, confidentiality attacks and model flaws. The duty applies from 2 December 2027 to stand-alone high-risk systems and from 2 August 2028 to systems built into regulated products.
Today most organisations can produce a policy document. Very few can produce evidence of what their agents actually did.
How it works
Inspect. Decide. Block. Record.
Four things, in order, with a deliberate discipline at each step.
2. Decide
You choose which threat classes are blocked and from what severity. Everything else is allowed and recorded.
3. Block
As a gateway, a malicious call is refused before it reaches the tool; inside Cyron On-Premise, the source is blocked at the kernel.
4. Record
Every detection, blocked or not, becomes durable evidence carrying its class from a public standard.
The discipline that differentiates it
No finding is not “safe”.
Every finding records something observed in live traffic. Cyron AI Security never presents the absence of a finding as proof of safety, and its transparent control status report shows exactly what is inspected. That is the first thing an auditor checks.
What every detection gives your audit, risk and compliance functions:
- A record, whether the exchange was blocked or allowed
- Its class from the OWASP Top 10 for LLM Applications (2025) or the OWASP Top 10 for Agentic Applications (2026)
- A deterministic, explainable verdict: the same exchange always gets the same verdict
- A place in the transparent control status report, which shows exactly what is inspected
This refusal to convert silence into assurance is the product's core commercial promise, because it is precisely what an auditor challenges.
What it deliberately does not do
Scope honesty is a selling point in this market, so the refusals are stated rather than buried.
- It does not map findings to specific regulatory obligations. It produces the evidence and the provenance. Claiming a technical finding discharges a named legal article is the overreach that discredits vendors in audit conversations. That mapping will be the job of Cyron AI Compliance.
- It does not address model quality, bias or fairness. Its scope is security: reproducible, attacker-triggerable, with a confidentiality, integrity or availability impact demonstrated in practice.
- It does not replace existing network, endpoint or API security. It addresses the agent layer those controls do not observe.
Standards coverage
A detection vocabulary auditors already recognise.
Findings are expressed in public, citable taxonomies rather than categories a vendor invented.
| Attack class | Where it is catalogued | What Cyron AI Security reports |
|---|---|---|
| Tool-description poisoning and hidden instructions | OWASP LLM01:2025; OWASP Agentic ASI04 | Detected in the tool list |
| Rug-pull, tool shadowing, weak schemas | OWASP Agentic ASI04 | Rug-pull: detected when a tool definition changes after approval. Tool shadowing and weak schemas: detected in the tool list |
| Injection through a tool’s output | OWASP LLM01:2025 | Detected in the tool response |
| Secrets and personal data in tool arguments; data moving between tool servers | OWASP LLM02:2025 | Detected, and blockable by class |
| Responses that break their declared schema | OWASP LLM05:2025 | Detected |
| Shared credentials and confused deputy | OWASP Agentic ASI03 | Detected |
| Session smuggling, delegation replay and transitive trust between agents | OWASP Agentic ASI07 | Detected |
| Adversary techniques against AI systems | MITRE ATLAS | Described in MITRE ATLAS vocabulary |
Deployment
It runs where your data already lives.
Cyron AI Security runs entirely inside your own infrastructure, including fully air-gapped environments, and never transmits data outward. For regulated buyers this is not a preference, it is frequently a procurement precondition.
- Fully air-gapped, with no call-home and no GPU required
- Signed, encrypted offline updates; keys created on site
- A transparent control status report
- Two roles: a standalone gateway, or integrated with Cyron API Security in Cyron On-Premise
Where it sits in the loop
Cyron AI Security is the measurement layer. Cyron API Security sees what reaches your APIs. Cyron AI Security inspects what your agents send to tools and to each other. Cyron AI Compliance, in development, will turn those findings into attested filings.
Where we’re heading. We are building deeper behavioural insight for every agent and a direct path from agent evidence into Cyron AI Compliance.
See all three productsFAQ
Questions teams ask first.
The traffic between your AI agents and the MCP tool servers and A2A agents they call: tool lists, tool calls, tool responses and agent-to-agent messages.
Yes, for the threat classes and severity you choose: inline as a gateway, or at the kernel inside Cyron On-Premise.
Guardrails and LLM firewalls filter prompts and model output. Cyron AI Security works at a different boundary: the tools and agents an agent calls. It reads tool descriptions, calls and responses, which is where tool poisoning, rug-pulls and exfiltration through tool arguments happen.
Because no finding does not mean safe. It reports what it observed, and its transparent control status report shows exactly what is inspected, so nothing is silently assumed.
It runs entirely inside your own infrastructure, including fully air-gapped environments, and never transmits data outward. Updates arrive as signed offline bundles and keys stay with you.
Findings are classified to the OWASP Top 10 for LLM Applications 2025 and the OWASP Top 10 for Agentic Applications 2026. It also uses MITRE ATLAS vocabulary.
No. It addresses the agent layer that those controls do not observe. Network and API controls see an authorised application making authorised calls; what they cannot see is that the instruction to make those calls arrived inside a poisoned document or a manipulated tool description. It is designed to run alongside Cyron API Security.
Now, on-premise, standalone or as part of Cyron On-Premise. Evaluations run in your own environment.
Measure your agents before someone else does.
An evaluation runs against your own agents, in your own environment. You keep the findings.