Use the AI layer that matches the risk. Model-layer issues belong with LLM application controls, agent behaviour belongs with agentic controls, and server and tool enforcement belongs with MCP governance. If those layers are collapsed into one review, gaps appear at the handoff points.
Audit MCP at the boundary where control actually changes
Teams should audit MCP governance as a boundary-control problem, not as a generic “AI security” review. The key question is whether each layer is enforcing the right decision at the right place: model-layer controls for LLM behavior, agent controls for delegated action, and MCP server controls for tool access and authorization. That separation is what prevents blind spots at handoff points.
For the MCP layer itself, the audit should prove that the server is acting as an enforcement point, not just a transport wrapper. The most relevant check is whether tool calls, scopes, audiences, and session boundaries are enforced by the MCP server and not implicitly trusted because the upstream app is “safe.”
In practice, this means reviewing where policy is decided, where it is enforced, and where an assumption is handed off to another component. If the same review tries to cover prompt safety, agent autonomy, and tool permissions in one control bucket, the result is usually shallow evidence and weak ownership.
Separate model, agent, and server evidence in the audit trail
An effective audit asks for different evidence at each layer. For the LLM app, teams should show prompt handling, output handling, and any guardrails that shape model behavior. For the agent, they should show how actions are authorized, constrained, logged, and bounded. For MCP, they should show how tools are registered, how calls are authenticated, and how the server prevents unauthorized capability use.
That separation matters because a green result in one layer does not compensate for a failure in another. An application can have strong model safeguards and still be exposed if the agent can invoke a dangerous tool through an under-checked MCP server. Likewise, a well-governed MCP server does not fix an agent that is allowed to chain actions beyond its intended job.
Teams auditing this boundary should also trace one or two real workflows end to end. The goal is to verify that the documented architecture matches the actual execution path, especially where an LLM output becomes an agent decision and then becomes a tool call.
Use the right references for MCP, agents, and adjacent trust boundaries
The most useful references are the ones that match the layer being reviewed. For agent behavior and delegated authority, OWASP Agentic AI Top 10 is a strong fit because it frames identity abuse, tool misuse, and agent coordination failures as distinct risks. For MCP transport and authorization mechanics, Model Context Protocol: Authorization specification is the clearest source for how servers should treat tokens, audience binding, and resource-server behavior.
Where teams want a broader governance lens, NIST AI Risk Management Framework helps structure accountability, testing, and oversight without collapsing distinct control layers. If the review includes vendor, assurance, or third-party governance, SOC 2 Trust Services Criteria can support the assurance side of the conversation, especially where service operators are expected to prove control design and monitoring.
For teams that need a practical threat-modeling reference around autonomy and orchestration, CSA MAESTRO agentic AI threat modeling framework is useful because it keeps the review focused on multi-agent behavior, autonomy, and tool-use risk rather than on generic AI narratives.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP API Security Top 10 and CSA MAESTRO address the attack surface, NIST AI RMF sets the technical controls, and SOC 2 (AICPA) defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent governance must show how delegated authority is bounded at runtime. |
| Recommendation — Enforce least-privilege agent permissions and review tool authorization paths. | ||
| NIST AI RMF | GV — Govern | MCP governance needs accountable oversight, roles, and control ownership. |
| Recommendation — Define ownership, approval, and monitoring responsibilities for each AI layer. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | MCP servers expose callable functions that must be authorization-checked. |
| Recommendation — Verify that each MCP tool call is authorized before execution. | ||
| SOC 2 (AICPA) | CC6.1 — Logical Access Security Software, Infrastructure, and Architectures | The question concerns assurance over access enforcement across service layers. |
| Recommendation — Document and test access controls that govern AI, agent, and MCP actions. | ||
| CSA MAESTRO | AIS — Agentic Security | Agentic orchestration and tool use are central to the audit scope. |
| Recommendation — Model agent-to-tool trust boundaries and test them for abuse paths. | ||
Practitioner Guidance
What to verify: Ask for a control matrix that maps each workflow to exactly one primary enforcement layer, with named owners for model behavior, agent behavior, and MCP server authorization. If the same control is claimed to cover all three, treat that as a review gap until the evidence shows otherwise.
What to prioritise: Start with the handoff from agent to MCP server, because that is where the most dangerous trust assumption usually lives. Then verify that tool scope, session scope, and revocation are actually enforced at runtime, not just documented in design reviews.
Common mistake: Treating prompt filtering as if it were the same thing as tool governance. A clean model response does not prove safe tool use, and a safe tool registry does not prove safe agent behavior.
Practitioner takeaway: The audit should prove that each layer enforces only the decisions it can actually make, and that no critical trust decision disappears in the gap between the LLM, the agent, and MCP.
Related resources from NHI Mgmt Group
- How should security teams govern an AI gateway that brokers LLM traffic, MCP servers, and agents across enterprise environments?
- How should security teams govern shadow AI across agents, MCP servers, and GenAI apps?
- How should security teams make NHI best practices usable across the business?
- How should security teams use IAST and RASP in NHI governance?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org