A sentinel on every agent message. Injection sanitized, replays denied, impersonation caught, tool use authorized. Fail-closed, and receipted.
Your agents are running right now, calling tools, messaging each other, acting on user accounts. Agent-Sentinel stands guard on that traffic continuously: every inbound message passes a fail-closed sweep (sanitize, replay-guard, authorize) and leaves an audit receipt, so "who authenticated this action and was it allowed" has a ledger answer, per message, not a quarterly guess.
Book a sentinel evaluation Read how we guard our own mesh
THE PROBLEM
The industry shipped agents faster than it approved them. Surveys put agent adoption around 80.9% of organizations, while only about 14.4% report their agents are security-approved. That gap is not laziness, it is that the old controls assume a human behind every action. When the actor is an agent, the basic questions break down. Who authenticated this message, the user, or an agent claiming to be the user's agent? Is this request fresh, or a replay of one captured an hour ago? Did an instruction buried in a document quietly change what the agent is doing? And is this agent actually allowed to call this tool, or did it just try because a prompt told it to? A pen test does not answer these continuously, and a model eval never sees the mesh at all. From August 2, 2026, the EU AI Act's Article 15 makes resilience and cybersecurity a standing obligation for high-risk systems, and standing obligations need standing controls, not annual PDFs.
HOW IT WORKS
Agent-Sentinel is a per-message integrity sweep, three fail-closed gates and a receipt, run on the same pattern engine that runs the agents:
- Gate 1, sanitize. The inbound payload is checked against injection shapes (prompt injection, pattern injection, log injection). A violation rejects the message, it does not "flag it for review later." - Gate 2, replay-guard. Timestamp freshness plus nonce deduplication. A replayed or re-ordered message is denied before it reaches the agent, which is how impersonation-by-capture actually gets used. - Gate 3, authorize. Bouncer checks the requested action against the principal's real grants. An agent asking for a tool it was never granted, or a principal that does not match its claimed source, is denied. Fail-closed means an unavailable authorizer is a denial, never a pass. - The receipt. Every sweep writes a security audit event carrying all three gate results, the message id, the principal, and the requested action. The ledger is what you hand the security reviewer who asked "who authenticated your agents."
AEGIS and Sentinel are two halves of one line: AEGIS attacks your agent once and reports what broke in, Sentinel stands on the wall afterward. The offensive probes that test these exact gates (message replay, message ordering, agent impersonation, prompt injection) live in the AEGIS suite, so the defense gets attacked by its own sibling.
WHAT YOU GET
- A continuous integrity sweep (AYA-3SPN-BOUNCER-AGENT-SENTINEL-v1): injection sanitization, replay/ordering defense, and grant-checked authorization on every inbound agent message, composed from defensive atoms already in the engine. - A per-message audit ledger: who authenticated, what was requested, which gates passed, the artifact that turns "we think it is fine" into entries with timestamps. - Fail-closed semantics throughout: a gate that cannot run denies, it never waves traffic through. - A defense that pairs with its own red team: the AEGIS probes for replay, ordering, impersonation, and injection are the offensive twins of these gates, so you can attack what you deployed.
WHO IT IS FOR
Platform teams running multi-agent systems in production, where agents message each other and call tools on user accounts. Security teams being asked to approve agent deployments this quarter with controls that were designed for humans and web apps. Healthcare and finance teams whose auditors ask who-did-what per action, and need the answer to survive the follow-up question. It sits next to AYA Bouncer (identity and consent, the front door) and AYA Red Team (AEGIS, the break-in team) as the always-on defensive member of the AYA security line.
PRICING
Prices are hypotheses we are validating, not commitments.
- Pilot. A sentinel evaluation on one agent lane: the sweep run over a captured message corpus from your mesh, delivering gate-by-gate findings (injection, replay, unauthorized action) and the receipt ledger. - Subscription. The sweep enforced continuously on live agent traffic, with the ledger as your standing who-did-what artifact and alerts on gate denials. - Platform. Sentinel as the integrity layer of your agent mesh, paired with AEGIS assessments on every release, the offensive and defensive halves on one engine.
A product is only sellable once its deliverable runs with a receipt. The defensive atoms are real and on disk; a live continuous run on your traffic is scoped with you first.
PROOF (we dogfood this)
Sentinel packages the defenses AYA's own architecture is built around. AYA's mesh is a Pure Message Architecture, agents only talk through the bus, which is exactly the surface these gates guard. The replay/nonce defense span and runtime-defense span already exist in AYA's own security suite, Bouncer authentication and authorization is the live front door of our deployed instance today (every authenticated action passes it), and when we want to know whether the gates hold, we fire the AEGIS impersonation, replay, and injection probes at our own deployment and read the findings.
HONEST NOTE
What is true: the four composed capabilities (input sanitizer, replay guard, Bouncer authorization, security audit event) are real, verified files in the pattern engine, the new sweep span composing them is PQS-validated (93, grade A), and Bouncer auth runs live on our deployed mesh right now. What we will not claim: that this exact composed sweep already runs on every message of our production traffic, or anyone's. It has not been executed as one span on a live lane as part of this launch build, that needs a booted mesh and a wired message lane, and it is the next owed step. When the first live sweep denies its first real replay and writes the receipt, we will show the receipt.
*This page is a specification. The capability it describes is not built yet, and nothing here is a claim that it runs today.*