Agentic AI Security Solutions Need Runtime Trust, Not Just Platform Coverage

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:

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.

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:

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.

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.

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.

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.

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:

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.

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.

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.

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.