What frameworks should teams use for MCP and AI governance?

Why This Matters for Security Teams

MCP governance is not just about a protocol setting or a connector inventory. It is about controlling how autonomous systems reach tools, secrets, and data once they are allowed to act. For that reason, teams usually need to combine a baseline security framework such as the NIST Cybersecurity Framework 2.0 with agent-specific guidance such as the OWASP Agentic AI Top 10. NHIMG research on MCP server security shows why this matters: 24,008 unique secrets were exposed in MCP configuration files in 2025 alone.

That number is not a theoretical risk signal. It reflects a common failure pattern where the control plane is treated as safer than the model-driven workload it enables. In practice, MCP servers can become a high-trust bridge into production systems, and a weak connector policy can turn one prompt into broad tool misuse. The right governance approach is to evaluate access, logging, and response together with prompt abuse, connector abuse, and secret exposure. In practice, many security teams encounter MCP misuse only after a connector has already been used to reach something it should never have touched.

How It Works in Practice

Teams should map MCP and ai governance to three layers: platform control, agent behavior, and identity discipline. At the platform layer, NIST CSF 2.0 supports the fundamentals: asset visibility, access control, logging, detection, and recovery. At the agent layer, the OWASP Agentic AI Top 10 helps teams look for tool misuse, prompt injection, connector overreach, and unsafe autonomy boundaries.

At the identity layer, NHI principles become important because MCP-enabled workflows often act like non-human identities with delegated authority. That means the question is not only “is the service authenticated” but also “what can this workload do, under what context, and for how long.” Current guidance suggests using short-lived credentials, scoped tool permissions, centralized logging, and policy evaluation at request time rather than relying on static allowlists alone. NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and Top 10 NHI Issues are useful when teams need to translate that into identity lifecycle controls.

• Inventory every MCP server, connector, and secret source before enabling broad agent access.
• Scope tool permissions per workflow, not per platform deployment.
• Log prompt, tool, and credential events with enough context to reconstruct agent action.
• Tie approval to runtime policy, especially when an agent can chain tools across systems.
• Rotate and revoke secrets aggressively when connectors are reused across teams or models.

These controls tend to break down in highly distributed environments where teams can deploy new MCP servers faster than governance can update policies.

Common Variations and Edge Cases

Tighter MCP governance often increases operational overhead, requiring organisations to balance faster experimentation against stronger control. That tradeoff is especially visible in prototype-heavy AI programs, where teams want broad access for rapid testing but also need to prevent connector drift, secret sprawl, and unreviewed tool chaining. Best practice is evolving here, and there is no universal standard for this yet.

For regulated environments, teams often extend the baseline with NIST AI Risk Management Framework and the NIST AI 600-1 Generative AI Profile to address accountability, monitoring, and human oversight. Where agents are making workflow decisions, teams should also consider whether policy must be intent-based rather than purely role-based. For background on the broader governance gap, NHIMG’s Ultimate Guide to NHIs — Standards is a useful reference point.

Edge cases include local MCP deployments with no central broker, vendor-hosted connectors that inherit opaque permissions, and multi-agent chains where one model’s output becomes another model’s action trigger. Those setups are hardest to govern because control points are fragmented and ownership is unclear.

Related resources from NHI Mgmt Group

• Which frameworks should teams use to assess OT secure remote access governance?
• How should security teams use IAST and RASP in NHI governance?
• How should teams use cybersecurity benchmark reports in identity governance planning?
• How should teams use DSPM findings in identity governance reviews?