Why AI Agent Security Still Fails After Governance: Runtime Trust After Intent Detection

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.

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.

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.

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.

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.

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.

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:

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.

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.