AI agent security still fails after governance because policy, access, and detection do not automatically decide whether the next action is trustworthy in context. Governance answers who owns the workflow and what is broadly allowed. Intent detection helps surface suspicious behavior. Runtime analytics helps show drift and sequence. Runtime trust is the layer that decides whether the already-allowed workflow should still act now — and most stacks stop one sentence before that answer.
AI agent security is getting a little more honest. Buyers now hear that governance alone is not enough. They hear about AI intent detection, runtime AI analytics, drift monitoring, and agentic threat detection. That is progress. It means the market is finally moving past the fantasy that a policy document, permission model, or static approval flow settles everything important.
But a lot of public guidance still stops one sentence too early. Detection can tell you that something changed. Governance can tell you who owns the workflow. Observability can show you the path the agent took. None of those, by themselves, answer the last operational question: should the already-allowed workflow still be trusted to take this tool call, follow this callback, carry this MCP handoff, or reach this endpoint right now?
That is the runtime-trust gap. It is also the clearest place Sunglasses can stay narrow and useful. If you are already working through how Sunglasses works, reading the Sunglasses manual, or reviewing the FAQ, the practical takeaway is simple: governance can reduce exposure, but runtime trust still decides the next move.
What governance, intent detection, and runtime analytics get right
It is worth being fair here. AI governance is not fake work. Teams should know which agents exist, what data they may touch, what tools they may call, which approvals matter, and who is responsible when the workflow goes wrong. That is how enterprises move from vibes to operating discipline.
Intent detection also solves a real problem. When an agent starts behaving differently, accepts a strange instruction pattern, retries in an unusual cadence, or begins steering toward a weird destination, you want that surfaced early. Runtime analytics matters for the same reason. It helps operators see the shape of activity instead of waiting for a headline-level breach.
Those layers do real work because they reduce uncertainty and shrink blast radius. They make the environment more legible. They make it easier to know which workflow changed and which control failed. They are absolutely part of a serious AI agent security program.
The honest problem is narrower: they still do not finish the action-time decision. A workflow can be well-governed, richly observed, and visibly flagged while the system still lacks a clean rule for whether the next action should happen. That is why teams who invest in governance can still watch a bad decision happen in slow motion.
Plain-language explainer: what the stack misses at runtime
Imagine a support agent with a clean enterprise setup. It has an approved persona, a scoped tool list, a documented escalation flow, and access only to the data it needs. The platform logs every step. A monitoring layer scores risky patterns. A governance team can explain the workflow on a whiteboard in five minutes.
Now the agent reads a tool result that recommends a temporary fallback queue. A callback tells it to continue on a different internal route. A connector note says urgent cases can use a partner endpoint for faster turnaround. A retry loop starts preferring a path the original workflow never emphasized. None of that has to violate the formal policy. None of it needs to look like an attacker wearing a ski mask.
This is where AI agent security breaks in practice. The workflow stays inside the broad permissions model, but the live meaning of the next step changes. The system can detect that the path is different. It can log the sequence. It can even label the drift as interesting. But someone still has to decide whether the agent should trust that new route enough to act.
That missing judgment layer is why "after governance" is the right frame. The problem is not before policy. It is what happens once policy says the workflow may proceed and runtime conditions start changing underneath it. This is also why the Sunglasses CVP program tests specifically for this class of runtime-trust gap — not just governance coverage.
Why detection is not the decision
Detection is necessary because without it, the team is blind. But detection is not the same thing as decision. A dashboard can show suspicious retry cadence. An intent model can tag a tool output as risky. A behavior graph can show that the workflow drifted toward a new endpoint. Useful. Still incomplete.
Operators do not win just because they noticed the problem one step earlier. They win when the system has a defensible rule for what to do next. Should the callback be followed? Should the MCP action be paused? Should the destination change require approval? Should the agent treat the tool output as descriptive data or as authority-bearing guidance? Those are runtime trust questions.
This is also why public vendor language often creates a gap Sunglasses can exploit honestly. Broad platforms talk about posture, visibility, policy, and lifecycle because those are real enterprise categories. Sunglasses does not need to out-platform them. It needs to finish the sentence they leave incomplete: after detection, what still decides whether the workflow should act?
A practical way to say it is simple: detection tells you something changed; runtime trust decides whether the changed workflow still deserves action authority.
Three concrete attack examples
1) Intent is flagged, but the workflow still follows the callback
A support agent receives a tool response that includes a callback URL and a note that this path is now preferred for urgent requests. The observability layer notices the callback is unusual. The intent system marks the response as medium risk. But the workflow still follows it because nothing in the runtime path says "flagged" should translate into "do not act yet." The system saw the drift. It just did not convert that signal into a decision.
2) Governance is correct, but an MCP handoff quietly changes authority
An agent is allowed to use one approved MCP server for retrieval and one for ticket creation. During a normal sequence, a tool output nudges the workflow toward a different follow-up action that remains technically inside the approved category of work. Authentication is still valid. The tools are still on the list. Yet the handoff now points the workflow toward a more sensitive action path than the operator expected. This is where MCP security and runtime trust meet: protocol hygiene matters, but so does evaluating whether the next allowed step should still be trusted.
3) Runtime analytics sees destination drift, but no one owns the stop/go call
A coding or operations agent starts retrying outbound requests toward a new endpoint. The analytics layer shows the pattern clearly. The governance team can later explain which system approved the workflow. But in the live moment, the agent still keeps going because no control translates "destination drift detected" into "hold this action pending review." The environment is observable. The decision is still missing.
How Sunglasses catches it
Sunglasses fits as a provider-agnostic runtime-trust layer. It is not pretending to be the whole governance platform, the whole AI-SPM layer, or the whole analytics stack. It is useful at the narrower point where trust-bearing text and workflow guidance start reshaping what an already-allowed agent believes it should do.
That includes prompts, tool descriptions, YAML, runbooks, callback instructions, connector notes, policy fragments, MCP-adjacent metadata, and ordinary-looking operational text that can quietly widen authority. Those surfaces matter because they often decide how the workflow interprets the next action long before a human notices the pattern in a dashboard.
This is why Sunglasses is especially useful after governance and detection are already in place. Once the broad control stack exists, teams need help inspecting the language and metadata that can turn a technically allowed workflow into an unsafe live action. The practical starting point stays simple:
pip install sunglasses
sunglasses scan <path>From there, review anything that widens scope, changes destinations, reframes policy, normalizes a fallback path, softens a guardrail, or turns descriptive output into executable trust. In other words: detect the drift, then inspect the words and metadata that try to turn drift into action. The full detection pattern library — covering callback trust manipulation, MCP authority escalation, and cross-agent scope creep — is documented on the attack patterns page.
- Governance can define roles, approvals, and control boundaries.
- Intent detection can flag risky prompts, unusual paths, or agent drift.
- Runtime analytics can show how a workflow is behaving over time.
- Runtime trust still has to decide whether the next tool call, callback, MCP action, or outbound request deserves confidence.
If your stack stops before that last question, you have better posture, but not necessarily better decisions. The Sunglasses scanner runs locally, MIT licensed, no telemetry — built to sit in front of agent workflows without adding latency overhead that makes production deployment impractical.