They should split governance into two layers. The IdP should decide whether the user or group may reach the MCP server, while a gateway or policy engine should decide which tools, actions, and logs are permitted. That separation keeps enterprise authorisation consistent without turning broad access into unchecked runtime privilege.
Why This Matters for Security Teams
Once EMA introduces model-driven execution into MCP workflows, the risk is no longer just who can connect to the server. The real question is what the agent can do after it connects, especially when tool use, context chaining, and runtime decisions happen faster than human approval. Static IAM is useful for initial reach, but it does not govern autonomous action well. That is why current guidance increasingly separates identity access from tool authorisation, as reflected in the OWASP Agentic AI Top 10 and NHIMG research such as OWASP Agentic Applications Top 10.
The practical issue is that MCP deployments often blur server access, tool scope, and secret handling into one control plane. NHIMG’s The State of MCP Server Security 2025 found that only 18% of MCP server deployments implement any form of access scoping for tool permissions, which shows how often teams stop at coarse gatekeeping. Security teams need a governance model that treats server reach, tool invocation, and logging as distinct decisions. In practice, many security teams encounter excessive runtime privilege only after an agent has already chained tools and exposed data, rather than through intentional access design.
How It Works in Practice
Security teams should govern MCP access in two layers. First, the identity provider decides whether a user, service account, or group may reach the MCP server at all. Second, a gateway, broker, or policy engine decides what that session may do once connected. That second layer should evaluate tool names, arguments, resource targets, and log visibility at request time, not just at login. This is where policy-as-code becomes essential, because MCP access is closer to runtime authorisation than to traditional app sign-in. NIST’s Cybersecurity Framework 2.0 and SP 800-53 Rev 5 both reinforce the need for least privilege, logging, and continuous control, which maps cleanly to this split.
In operational terms, good MCP governance usually includes:
- IdP-based admission control for who may connect to the server.
- Tool-level allowlists tied to role, project, or environment.
- Short-lived session tokens instead of durable secrets where possible.
- Explicit logging rules for prompts, tool calls, and returned data.
- Step-up approval for sensitive actions such as writes, deletes, or exports.
That pattern aligns with NHIMG’s broader NHI guidance in the Ultimate Guide to NHIs, especially where credentials and access scope must be managed separately across a lifecycle. It also fits the reality that MCP servers often expose credentials in configuration files or over-broad tool endpoints, creating a path from simple connectivity to unintended privilege. These controls tend to break down when the MCP server is deployed as a shared internal utility with no policy enforcement point, because the server itself then becomes both the gate and the judge.
Common Variations and Edge Cases
Tighter MCP controls often increase operational overhead, so organisations have to balance friction against the risk of uncontrolled tool use. There is no universal standard for this yet, especially when MCP is embedded inside agentic workflows that change behaviour based on prompt context, task state, or upstream tool output. In those environments, a static role model can look clean on paper but still fail at runtime.
One common variation is delegated access, where a human authorises an agent to act on their behalf. Best practice is evolving, but the safer pattern is to bind that delegation to a narrow task, a short TTL, and explicit revocation, rather than letting the agent inherit broad standing rights. Another edge case is logging. Full prompt and tool logging can improve investigation and audit, but it may also capture sensitive data, so policy should distinguish between security telemetry and business content. NHIMG’s Top 10 NHI Issues is useful here because it highlights the recurring failure modes around over-privilege and lifecycle gaps.
For teams comparing agentic governance approaches, the emerging consensus is that MCP should not be trusted as an access control boundary by itself. The boundary needs to sit above it, with contextual authorisation and explicit tool governance. That recommendation is consistent with OWASP’s OWASP Non-Human Identity Top 10, but implementation details still vary by stack. In environments with multiple agents sharing one MCP server, the model becomes hardest to sustain because attribution, least privilege, and per-agent scoping all become ambiguous at once.
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, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Agent tool use needs runtime controls beyond simple server access. |
| CSA MAESTRO | TA2 | MAESTRO addresses governance for agent tool access and orchestration. |
| NIST AI RMF | AI RMF supports governance of dynamic AI behaviour and oversight. | |
| OWASP Non-Human Identity Top 10 | NHI-03 | MCP access often fails through weak secret and credential governance. |
| NIST CSF 2.0 | PR.AC-4 | Least privilege and access control map directly to MCP governance. |
Add policy checks for every tool call and deny unsafe autonomous actions by default.
