Imagine you're a foreign correspondent for a major newspaper. In tracking down a breaking story, you find yourself in a country where you don't speak the local language. You don't know the local power structure. Your success depends on a network of trusted, vetted locals who support you: a fixer who knows the city, a translator for documents, a source inside the ministry, a photographer who can get places you can't as a foreigner.
They came recommended. Each one essential to work you can't do alone in a reasonable amount of time. You trust them even though you don't really have a choice. You can't verify references; you can't tell when a translation is shaded; you can't independently check whether the source is who they say. You do your best to evaluate what they give you in part and in sum, fit it together, write the piece, file the story.
If one helper is lying, then the story prints with a lie in it. If some of the helpers are coordinating, though, the story you wrote is exactly what someone else wanted written, and you did it for them.
That's roughly how an AI agent works when it can call MCP servers. The model can't speak the languages your systems speak: databases, file stores, APIs, and internal tools. It depends on — and because it has to, trusts — MCP servers to translate, fetch, and act on its behalf. Each server self-describes what it does. The agent picks based on those descriptions. It composes them into work, and the work gets committed to your real systems.
The risk isn't in any one helper feeding you a lie. It's the coordination to subvert your intention and awareness.
Why individual review can't catch composition
Here's what that looks like inside an enterprise.
Your security team approved three MCP servers for an internal agent. The first reads public Slack channels. Scoped, reviewed, signed off. The second searches the engineering shared drive. Scoped, reviewed, signed off. The third sends emails on behalf of users. Authenticated, signed off, outbound traffic logged. Each server, reviewed on its own, looked safe.
The agent with all three reads Slack to identify who's working on what sensitive project, pulls the project docs from the shared drive, and emails them to an attacker-controlled address. Three legitimate capabilities. One catastrophic outcome.
Each server did exactly what it said it would. The agent's behavior was the composition. The composition is what no one reviewed.
If you're running this in Azure AI Foundry, the moving parts are concrete: your agent is an Entra-identified deployment in Foundry Agent Service, its tools are MCP server endpoints (public, private, or bundled through Foundry Toolboxes), Foundry Control Plane gives you fleet visibility, and tracing through Azure Monitor captures every tool call. None of that is missing in Foundry, but the composition isn't represented: the platform shows you what each agent did, not what each agent's capability set means it can do.
Every enterprise security review model shares an assumption: that you can decompose the system into reviewable units like vendors, assets, APIs, and packages; evaluate each unit on its merits; and aggregate the results to understand the system's risk profile.
Reviews are per-vendor; agent risk is per-composition. Your third-party risk management (TPRM) process evaluates a vendor and produces a risk tier for that vendor. But the risk attached to an MCP server is a function of what other servers the same agent can also reach. A document-read server is low-risk in an isolated agent. It's a critical-tier risk in an agent that can also send email externally. Per-vendor review can't represent this since the same server has different risk profiles in different agent contexts, and the per-vendor tier is necessarily wrong in at least one of them.
Capability composition isn't a known risk category. TPRM risk frameworks have categories for data security, access controls, financial soundness, regulatory exposure. They don't have a category for "this vendor's tool, combined with other tools, produces emergent capabilities not represented in any individual review." Composition risk falls through the gaps because no one owns it.
Effective authority is computed at runtime. Even if you wanted to review compositions, you'd need to know which compositions exist. Most enterprises can't produce this list. The agent's tool set is wired up by developers, often without security in the loop (beyond having signed off on the original platform), and changes when a developer changes their mind. Yesterday's safe composition becomes today's exfiltration risk because someone added a fourth tool and your review process didn't fire because — technically — the fourth tool was already approved.
The result is a security review can sign off on every MCP server in your environment and still leave the actual risk completely unexamined.
For agent and MCP governance, the unit of risk review needs to be the agent-with-its-capability-set, not each server alone. Individual server review still matters but it doesn't substitute for composition review, and right now most enterprises are doing only the first.
Multi-Entity Governance and the composition graph
Your Configuration Management Database (CMDB) does one thing really well: it tells you what assets you have, who owns them, what risk tier they sit in, what their dependencies are. It is the foundation of how enterprise security reasons about its environment.
It cannot tell you what your agents can actually do.
That's the gap Multi-Entity Governance (MEG) is built to fill. MEG treats MCP servers (and models, systems, and agents themselves) as governed entities, like any mature security program covers its critical assets. But the entity card includes data your CMDB doesn't track:
- Co-deployment. Which agents currently have this MCP server in their tool set, and what other servers are co-deployed with it in each context. Without this field, you cannot reason about composition.
- Capability composition. The effective capability surface of each agent and the union of what its servers let it do, plus the emergent capabilities that come from combining them. This is the security-relevant view of the agent, and the one that maps to actual risk.
- Per-deployment risk tier. The same MCP server can be tier-2 in one agent and tier-4 in another. The tier travels with the deployment, not the server, because the risk does.
- Composition change triggers. When an agent's tool set changes, whether that's a new server added, existing server's tool description updated, or a different agent starts using the server, the agent's composition risk gets re-reviewed, not just the new server's individual record.
These aren't "extra fields." They're the data structure required to ask the question your CMDB cannot answer: what can the agent actually do, and is that what we authorized?
That's the substantive difference between MEG and adding MCP servers to your CMDB: a CMDB entry tells your team that the server exists and what it does. A MEG entity card tells your team what your agents do because the server exists, what other entities it composes with, and what changes about that composition should trigger a review.
This is the perspective Credo AI is building toward, and the perspective we think security teams need to adopt regardless of where they get their tooling from.
What changes at the operating level
If you accept that composition is where the security gap lives, three things change about how you run MCP security.
Risk-tier per agent-deployment, not per-server. Stop assigning a single risk tier to an MCP server in isolation. Tier the specific (agent, tool set) cluster. The same server can be low-risk in one agent and a critical-tier risk in another, and your tier needs to reflect the deployment, not the asset.
Run composition red-teams. For each agent, enumerate the capability set and run a structured "what could this combination do that we didn't authorize?" exercise. This is cheap with a 10-minute exercise per agent and catches the failures individual review structurally can't. If you don't have a process for this, you don't have a process for agent risk; you have a process for tool risk. It's also an easy task for your model of choice to propose these scenarios.
Trigger re-review on composition change, not server change. The CMDB-native instinct is to re-review when a server is updated. That's not enough. Re-review when an agent's tool set changes, when a new server is added, when an existing server's tool description changes, and when a different agent starts using the server. The trigger is composition-level because the risk is composition-level.
None of these require new tooling to start. They require an inventory of agents and their capability sets, and the discipline to look at compositions instead of servers. The MEG entity card is what makes this sustainable at scale, but the practice can start today with a spreadsheet.
Monday Morning Next Steps
Three things to do this week:
- Inventory by agent. List your agents. For each, list the MCP servers it can reach. That list is the capability set and it's the unit you're going to govern. (In Foundry, Foundry Control Plane plus the Entra agent-ID inventory give you most of the raw material; the work is producing the per-agent capability-set view, which the platform doesn't surface directly.)
- Red-team each composition. For each agent, run a 10-minute "what could these tools combined do that we'd never have approved as a single capability" exercise. Write down the worst cases. (Foundry's tracing is useful for seeing which compositions actually run in production, but the thought experiment runs against the inventory, not the trace.)
- Define your composition-change trigger. Decide who reviews when an agent's tool set changes: new server added, existing server's behavior changes, a different agent starts using a server you've already approved. (In Foundry, the underlying events live in Azure Monitor / Application Insights traces, and the AI Gateway pattern is the natural place to enforce a gate before an agent reaches a new server.)
The protocol will change but the composition gap won't.
DISCLAIMER. The information we provide here is for informational purposes only and is not intended in any way to represent legal advice or a legal opinion that you can rely on. It is your sole responsibility to consult an attorney to resolve any legal issues related to this information.
