AI-BOMs, discovery graphs, agentic red teaming, MCP inventories, and intent baselines are the right first sentence for enterprise AI security. They are not the final decision before an agent acts.
Why AI-BOM language is rising now
Enterprise AI security is becoming a lifecycle map. The current buyer language is not just "block prompt injection." It is: discover every agent, build an AI Bill of Materials, find shadow MCP servers, identify prompt-injection sinks, red-team multi-step agent behavior, baseline intent, generate policy, monitor runtime activity, and prove governance to security leadership.
That framing is useful because AI agents sprawl. A single organization can have Copilot Studio agents, Bedrock agents, Vertex agents, Salesforce Agentforce workflows, internal coding agents, GitHub-connected assistants, local MCP servers, generated connectors, package-manager access, browser sessions, and CI/CD pipelines. If security cannot see those objects, it cannot govern them.
But the lifecycle map also creates a trap. Inventory can start sounding like control. A graph can start sounding like trust. A red-team pass can start sounding like permission. A behavioral baseline can start sounding like a live allow decision.
That is the gap Sunglasses should own carefully. Do not attack the inventory layer — it is necessary. The stronger sentence is: AI-BOMs, discovery graphs, and red-team findings tell you what exists and what might go wrong; runtime trust decides whether the current action path is still safe after live context, tool output, callbacks, state, and evidence have shifted.
If you are new to where runtime trust sits in the full pipeline, the how it works overview places each layer from prompt to action.
Plain-language explainer
Imagine a security team that has done the responsible thing. They found their AI agents. They mapped the tools those agents can call. They listed MCP servers. They tied agents to owners, repositories, cloud accounts, permissions, and data paths. They ran red-team tests. They generated policies. They built an AI-BOM.
That team is safer than a team flying blind. But an agent action is not only a property of the inventory. It is a live chain of evidence: the prompt, retrieved documents, repository files, tool outputs, workflow memory, callback destinations, package metadata, timestamps, approvals, and the authority the agent is about to use.
A known agent can still read an untrusted README. An approved MCP server can still return poisoned output. A red-team baseline can still miss a new callback chain. A repository scan can still pass before a package endpoint drifts. An intent baseline can still classify behavior as normal while a forged receipt tells the agent that validation succeeded.
Runtime trust sits between that shifting evidence and the action. It asks: is the source valid, is the evidence fresh, is the scope still correct, did the destination change, does the action match the user's goal, and is this authority allowed for this moment? The Sunglasses manual provides a step-by-step treatment of how each of these checks applies in practice.
Teams that want to understand how these checks map to real model behavior can review the CVP evaluation reports, which walk through runtime-trust failures measured against frontier models.
AI-BOMs vs runtime trust
| Layer | What it helps with | What still needs runtime trust |
|---|---|---|
| AI-BOM / discovery graph | Which agents, models, prompts, tools, MCP servers, repositories, cloud services, and data paths exist. | Whether the live action path is safe after the agent reads new context, receives tool output, or follows a callback. |
| Agentic red teaming | Known attack paths, multi-turn failures, prompt-injection sinks, policy gaps, and likely exploit sequences. | Whether a specific new action is relying on trusted evidence or on a forged, stale, replayed, or scope-shifted signal. |
| Intent baseline | Typical agent behavior, anomalous sequences, tool/response mismatch, and identity-linked drift. | Whether this apparently normal workflow should still use authority now, for this destination, with this evidence. |
| MCP inventory / gateway | Known MCP servers, exposed tools, access policy, audit trails, and shadow-server discovery. | Whether this tool call, tool result, generated connector, or MCP handoff is valid inside the current workflow. |
| Usage control policy | Who may use which agent, what systems it can reach, and which actions are broadly forbidden. | Whether an otherwise allowed action has been induced by prompt injection, poisoned output, stale state, or callback drift. |
Three concrete attack examples
1. AI-BOM sees the MCP server; it does not trust the tool output
The inventory says the agent may call an internal MCP server for build status. The server is known, the owner is known, and the action is inside policy. During a release workflow, the tool returns "all checks passed" with a convenient deploy command.
The failure is not discovery. The failure is evidence trust. Runtime trust should verify that the result is fresh, source-valid, non-replayed, scoped to the right build, and actually authorized to trigger deploy. This class of attack — where a permitted tool returns adversarial output — is the core of MCP tool poisoning.
2. Red-team findings pass; the repository text changes the plan
A coding agent was red-teamed last week against common prompt-injection patterns. Today it reads a new README or issue comment that tells it to run a migration, install a helper package, or paste logs into a remote endpoint. The known test suite did not include this exact instruction chain.
Runtime trust asks whether untrusted repository text is trying to cross from advice into shell execution, package installation, data movement, or outbound callback authority. The agent instruction file poisoning blog covers this vector in detail, including how the same pattern appears across README files, config files, and inline comments.
3. Intent baseline says normal; callback drift changes the destination
The agent normally calls a support tool, summarizes a ticket, and sends a response. The behavior looks baseline-normal until a callback or generated connector changes the destination, expands the data scope, or asks the agent to attach internal context.
A behavioral baseline can flag anomalies. Runtime trust still needs to gate the action using source, destination, scope, freshness, and action binding at the moment of execution. The FAQ covers the most common questions about where runtime trust fits relative to monitoring and alerting layers.
How Sunglasses catches it
Sunglasses is not an AI-BOM platform, an agent-discovery graph, or a full red-team suite. That honesty matters. Sunglasses is the narrower runtime-trust layer for agent-visible evidence and action paths.
It scans prompts, retrieved context, tool outputs, handoff state, metadata, validation receipts, MCP/tool descriptions, and workflow evidence for patterns that turn approved authority into unsafe action. That includes indirect prompt injection, tool-output poisoning, forged receipts, state-board poisoning, context flooding, policy-scope drift, generated connector risk, and callback/destination changes.
The product sentence to repeat is simple: use AI-BOMs and discovery to know the agent environment; use runtime trust to decide whether the already-discovered, already-connected, already-permitted workflow should act right now.
Buyer-safe positioning: Sunglasses complements discovery, red-team, gateway, and usage-control tools rather than replacing them. The citation gap is the last decision before action. See how it works for where Sunglasses sits in a real agent pipeline.