Why visibility became a security category
Security teams are right to ask for agentic runtime visibility. An AI agent is not just a chat transcript anymore. It may browse pages, call MCP tools, inspect repositories, write files, open pull requests, run shell commands, post to a ticket, fetch package metadata, contact an API, or ask another agent to finish the job. Once the workflow crosses those boundaries, the old question, "what did the model say?" is too small.
The better first question is: what did the agent do across the full execution path? That is why the market is normalizing phrases like agentic runtime visibility, AI Detection and Response, agentic investigation, tool-use inspection, MCP traffic inspection, malicious tool-call detection, and evidence-backed AI-security alerts. These are useful controls. They make agent sessions observable enough for defenders to reconstruct state, detect suspicious transitions, and investigate whether a tool call or prompt injection changed the workflow.
But visibility is not the same as trust. A camera on a loading dock can show a package moving through the door. It does not decide whether this person, this badge, this package, this destination, and this hour are authorized together. AI-agent security has the same gap. Runtime visibility can show a session. Runtime trust decides whether the next action path is still allowed.
Plain-language definition
Agentic runtime visibility means the system can observe an autonomous agent while it acts: prompts, retrieved context, MCP tool descriptions, server responses, files, commands, callbacks, network destinations, memory, handoffs, and enforcement decisions.
AI Detection and Response for agents means the system can turn those observations into detections, investigations, policy actions, and evidence. It helps teams ask: did prompt injection occur, did the agent call a strange tool, did data leave the expected channel, did a tool response push the model into a dangerous path, and can we reconstruct the session afterwards?
Runtime trust is narrower and more immediate. It asks whether the agent should perform this specific action now. The answer has to consider source, freshness, scope, policy, identity, destination, approval path, and the current workflow state. If any of those changed, "the agent is allowed to use this tool" is not enough.
That distinction matters for AI agent security, agent hardening, and prompt-injection pattern detection. Most serious failures are not one big red flag. They are ordinary-looking steps that become dangerous when combined: a stale approval, a renamed endpoint, a poisoned MCP response, a file edit in the wrong directory, a callback that silently changes authority, or a package URL that no longer matches the reviewed dependency.
Three concrete agent failures visibility may see but not decide
1. The reconstructed session still leaves a stale approval problem
A coding agent wants to deploy after a green CI run. Runtime visibility can show the session: the PR comment, the CI result, the tool calls, the approval note, and the deploy command. Detection may even confirm that the approval was real at the time it was issued.
The runtime-trust question is different: is that evidence still fresh for this action? If the commit changed, the dependency graph shifted, the approval was scoped to a previous diff, or the destination environment changed, old proof is evidence, not permission. The deploy should be gated until freshness and scope are rechecked. This is exactly the class of failure the Sunglasses scanner looks for before the action crosses the boundary.
2. MCP traffic inspection sees the channel, but the response still needs action-time trust
An agent queries an MCP server for a data export, a repository search, or a cloud-resource lookup. A gateway or proxy may inspect the MCP request and response. That is valuable. It can detect suspicious tool descriptions, strange payloads, indirect prompt injection, oversized context, or data-exfiltration patterns.
The action-time question is whether this response should influence this agent's next action now. Did the server identity match the reviewed binding? Did the tool's declared capability match the actual response? Did the response add instructions that exceed the tool's authority? Did it redirect the agent toward an unreviewed destination? Runtime visibility can collect the trace; runtime trust decides whether the trace is enough to act on. See the FAQ for the full Sunglasses vs. gateway comparison.
3. Malicious tool-call detection may fire after the dangerous path already formed
A security system may detect that an agent attempted a malicious tool call: writing a secret to a public issue, sending code to an unfamiliar endpoint, or invoking a shell command with a payload derived from untrusted context. That detection is useful for investigation and response.
Sunglasses wants the earlier decision point too: before the call crosses the boundary. The question is not only "was this call malicious?" It is: does this action match the allowed workflow, the current role, the expected destination, the approved data shape, the fresh evidence, and the original user intent? If not, the agent should pause, ask for approval, or route through a safer path. The CVP program validates these controls end-to-end.
How Sunglasses catches it
Sunglasses is not trying to be a full AI Detection and Response platform. It is a smaller open-source scanner and runtime-trust vocabulary for the places AI agents turn text into action. That narrower scope is the point.
Sunglasses looks for patterns that make an action path untrustworthy: prompt injection, indirect instructions, tool-output poisoning, metadata smuggling, stale evidence, approval laundering, callback drift, endpoint drift, package-chain abuse, MCP scope changes, and policy-scope redefinition. Those patterns matter because they sit between "the workflow is visible" and "the workflow is safe to execute." The full attack patterns library now covers 852 patterns across 55 categories.
The repeatable bridge sentence: Runtime visibility shows what the agent did; runtime trust decides whether the next tool call, MCP handoff, callback, command, file edit, package endpoint, or outbound request should execute now.
That sentence keeps Sunglasses honest beside broader platforms. Visibility, investigation, threat hunting, and enforcement are legitimate layers. Sunglasses should not pretend otherwise. The missing layer is the action-time trust decision after visibility has already produced evidence. Install it with pip install sunglasses and see the scanner overview for wiring examples.
Runtime-trust checklist
When a visible agent session is about to become a real action, ask:
- Source: where did the instruction, tool output, context, or evidence originate?
- Freshness: is the proof still current for this exact action, commit, destination, and time?
- Scope: was the approval or policy granted for this workflow, or only for a nearby one?
- Identity: is the tool, MCP server, callback, package endpoint, or agent identity the reviewed one?
- Destination: is the data, command, or request going where the user and policy expect?
- State: did the workflow state change since the evidence was captured?
- Fallback behavior: did retries, alternate tools, or error recovery silently widen authority?
If the answer is unclear, the safe move is not to keep acting because the session is visible. The safe move is to stop the action path until the runtime trust evidence catches up. The Sunglasses manual covers integration patterns for each of these checklist items.