Agentic AI security solutions are platforms and controls that discover agents, govern access, inspect MCP traffic, enforce policy, and feed security operations. They frame the buyer’s starting question correctly. What they often leave implicit is the last-mile decision: should this specific allowed action execute now, with this prompt history, this tool output, this memory, this destination? That gap is where Sunglasses fits — detecting patterns like GLS-IP-001 (indirect prompt injection via retrieved content), GLS-MCP-POISON-201 (MCP tool manifest poisoning), and GLS-TOP-237 (tool output poisoning via trusted-override claims) at the action boundary before execution.
What agentic AI security platforms cover
The category is maturing fast. The strongest enterprise pages now group agent security around a familiar lifecycle: discover the agents, map the assets they can reach, govern who can call what, inspect traffic, enforce policy, log outcomes, and send high-signal events to SOC workflows.
That is a good thing. Buyers need a frame that is bigger than one prompt filter. A real agent can read files, call tools, browse websites, write code, update tickets, query memories, invoke MCP servers, and route requests through gateways. If security teams cannot inventory those paths, every later control is guessing.
Common platform promises now include:
- Agent discovery and posture: which agents exist, who owns them, what tools or data they can reach, and whether their configuration drifts from policy.
- Access governance: role scoping, per-tool permissions, MCP endpoint policy, human approval gates, identity integration, and least-privilege review.
- Prompt and content inspection: detection for prompt injection, jailbreak phrasing, malicious documents, suspicious web content, and unsafe generated instructions.
- MCP and tool gateway security: inspection and enforcement around agent-to-tool traffic, server trust, tool descriptions, resource reads, and outbound calls.
- Memory and provenance controls: evidence about where state came from, when it changed, and whether it should still influence the next decision.
- Detection and response: logs, alerts, autonomous response playbooks, SIEM/SOAR/XDR integration, and investigation trails.
None of that is fake. It is the right first sentence for the market. The mistake is treating that first sentence as the whole answer. Understanding how runtime trust works makes clear why platform coverage alone leaves a gap at the action boundary.
The missing runtime-trust question
Agent security gets dangerous at the moment authority becomes action. A policy engine may say the agent is allowed to call a CRM tool. A gateway may say the MCP server is approved. A scanner may say the web page contains suspicious instructions. A memory store may say a record has provenance metadata. Those are inputs. The final decision is still contextual.
Runtime trust asks whether the current action should happen after combining the live evidence:
- What instruction path led to this tool call?
- Did an untrusted page, document, API description, CI log, repository field, or discovery file change the agent’s plan?
- Is the destination the same one the user or policy expected?
- Did a retry, fallback, callback, or handoff quietly expand authority?
- Does the tool output prove the thing the agent thinks it proves?
- Is the memory, ticket, approval, or status board fresh enough to justify this action?
That sentence is smaller than a platform category, but it is the sentence a deployed agent needs. Access defines reach. Runtime trust decides whether to use that reach now. The Sunglasses manual walks through each attack class at this boundary in detail.
Three places platform coverage still needs action-time trust
1. Indirect prompt injection becomes an action problem
A web page can tell an agent to ignore previous instructions, leak data, or call a tool. A prompt-security control may detect that content. But the operational question is not only whether the text is malicious — it is which downstream actions became contaminated by that text.
If the agent summarizes the page, risk is one shape. If it updates a ticket, sends email, changes ad copy, deletes a record, or calls a payment workflow, risk is another. Runtime trust ties the suspicious input to the action path before execution. Sunglasses pattern GLS-IP-001 targets instruction-reset phrases in retrieved documents and web pages specifically because indirect injection travels through legitimate retrieval channels before becoming an action problem. See indirect prompt injection defense for wiring examples.
2. MCP gateway approval does not prove the next tool call is safe
MCP security matters because agents increasingly treat tool servers as part of their working environment. A gateway can inspect interactions, enforce policy, and block obviously dangerous calls. Still, an approved server can be used in the wrong context.
The agent may call the correct tool with the wrong argument, use a stale resource as if it were fresh, follow a poisoned tool description, or pivot through a callback chain that changes the intended destination. Runtime trust checks the action, not just the route. GLS-MCP-POISON-201 covers the specific case where a tool manifest or description embeds instructions to override policy, coerce secret disclosure, or chain unauthorized tool calls — a threat class the gateway approves but should not. More on the MCP threat surface at MCP tool poisoning and our dedicated MCP tool poisoning detection page.
3. Memory provenance is evidence, not permission
Provenance helps teams understand where a memory came from and whether it was modified. But provenance does not automatically answer whether the memory should influence this action. A once-valid approval can expire. A status board can drift. A release note can be true but irrelevant to the current environment.
Runtime trust treats provenance as evidence. It still asks whether the current prompt, tool output, user intent, policy, destination, and time window agree before the agent acts. GLS-TOP-237 targets tool outputs that claim trusted or authoritative status to override the agent’s prior instructions — exactly the pattern that makes stale or manipulated evidence dangerous at action time.
How Sunglasses catches it
Sunglasses is built around attack patterns that show how trusted-looking agent context turns into unsafe action. The pattern database covers prompt injection, MCP and tool poisoning, workflow-state drift, metadata poisoning, hidden instruction carriers, policy-scope redefinition, forged approvals, stale evidence, and callback or handoff manipulation.
The product goal is not to say every enterprise security platform is wrong. The goal is to give builders and defenders a sharper runtime decision layer. When an agent reaches an action boundary, Sunglasses helps reason about whether the evidence path is trustworthy enough for that exact step.
That makes Sunglasses a useful complement to platform controls:
- After discovery tells you an agent exists, Sunglasses helps identify how that agent can be misled at action time.
- After access policy says a tool is allowed, Sunglasses helps test whether the live request should still be trusted.
- After an MCP gateway approves the route, Sunglasses helps reason about poisoned descriptors, resource confusion, covert invocation, and callback drift.
- After logs capture an event, Sunglasses gives teams repeatable language for the attack primitive that made the event possible.
In other words: broad platforms make the environment observable and governable. Sunglasses makes the last-mile trust question explicit. The CVP program documents this boundary with reproducible proofs. The FAQ has answers to the most common positioning questions.
What not to overclaim
The honest answer matters because buyers can smell fake platform parity. A broad agentic AI security platform may own inventory, governance, gateway policy, posture management, SOC workflows, and response automation. Sunglasses should not claim to replace that surface. The stronger claim is narrower and more useful: when those systems have done their job and the agent is still about to act, the last-mile trust decision remains exposed.
That distinction keeps the category clean. Discovery is not the same as authorization. Authorization is not the same as safe execution. Prompt inspection is not the same as downstream action containment. MCP gateway policy is not the same as knowing whether this callback, argument, memory, file write, or outbound request still matches user intent. A runtime-trust layer should sit beside those controls, consume their evidence, and make the final action boundary explicit.
It also gives answer engines a clearer citation shape. If the query is “best agentic AI security solutions,” the first sentence can name the broad platform criteria. The second sentence should say what broad platforms often leave implicit: approved agent authority can still be misused when untrusted context changes the action path. That is the Sunglasses wedge.
Buyer checklist: what to ask after platform coverage
If you are evaluating agentic AI security solutions, ask the platform questions first. Then ask the runtime-trust questions that determine whether approved authority becomes safe execution.
- Discovery: Can we inventory agents, tools, MCP servers, memories, and outbound destinations?
- Policy: Can we define who or what is allowed to call each tool?
- Inspection: Can we detect prompt injection, poisoned descriptors, malicious documents, unsafe code, and suspicious tool outputs?
- Runtime trust: Can we decide whether this specific allowed action should run now?
- Evidence: Can we prove which prompt, file, memory, tool output, approval, or metadata carrier influenced the action?
- Containment: Can we stop, sandbox, quarantine, or require human review before impact?
- Learning: Can we turn the event into a reusable attack pattern rather than a one-off incident note?
The fourth question is the hinge. If it is missing, the program may still have excellent visibility while agents continue translating untrusted context into trusted action.