MCP governance should be shared, but the identity team must own entitlement, lifecycle, and audit state while the platform team owns request mediation. If one team tries to own both, organisations usually end up with a proxy that filters traffic but does not govern access.
Why This Matters for Security Teams
MCP governance is not just a tooling question. It is an identity control problem, because the real risk sits in who can obtain, use, revoke, and prove access, not only in how requests are proxied. That is why Ultimate Guide to NHIs treats lifecycle, visibility, and audit state as core governance functions, not optional extras. The platform team can mediate traffic, but only the identity team can ensure entitlement decisions are tied to accountable records and revocation workflows.
This matters even more when MCP is used to connect autonomous agents to internal tools. The agentic attack surface is already proving that scope control fails when access is granted once and assumed safe thereafter. In the OWASP Agentic Applications Top 10 guidance, the core concern is not simply malformed input but runtime behaviour that expands beyond intended scope. NIST’s NIST Cybersecurity Framework 2.0 also reinforces the need for clear ownership across governance, protection, and monitoring functions.
In practice, many security teams encounter MCP drift only after an agent has already used a legitimate path to reach an illegitimate outcome.
How It Works in Practice
The cleanest operating model is split ownership with shared policy. Identity teams should define the entitlement model, approval logic, joiner-mover-leaver lifecycle, audit evidence, and revocation standards. Platform teams should own MCP request mediation, connector health, service availability, and the technical enforcement layer that calls policy decisions at runtime. That division keeps the platform from becoming a shadow IAM system and keeps identity from losing operational context.
For autonomous systems, current guidance suggests moving away from static, always-on access and toward just-in-time, short-lived permissions. Agents should authenticate as workloads, not as human-like users, using workload identity primitives such as cryptographic tokens or SPIFFE-style attestations. Access decisions should be intent-based and context-aware, evaluated per request with policy-as-code rather than baked into a fixed role that assumes predictable behaviour. This is especially important when agents can chain tools, retry actions, or change plans mid-task.
Operationally, that means:
- issue ephemeral secrets with short TTLs and automatic revocation;
- separate who approves access from who runs the MCP gateway;
- record every entitlement, token mint, and tool invocation in an auditable trail;
- bind access to task context, not to broad standing privilege.
The governance case is not theoretical. NHI exposure is already widespread, and NHI Mgmt Group notes that 91.6% of secrets remain valid five days after notification, which shows how slowly revocation often happens in real environments. That is why the identity function must own lifecycle control, while the platform function enforces mediation against the current policy state. These controls tend to break down in highly distributed toolchains where MCP brokers, CI/CD jobs, and agent runtimes each mint credentials independently because no single team can see the full access path.
Common Variations and Edge Cases
Tighter governance often increases operational overhead, so organisations have to balance speed against assurance. That tradeoff becomes visible when teams want a fast developer experience for MCP while also demanding strict identity controls. Best practice is evolving, but there is no universal standard for whether the platform team or identity team should own the gateway itself. What is settled is the control boundary: the platform may run the mediation service, but it should not be the source of truth for entitlements.
In lower-risk internal environments, some teams let platform engineering manage the MCP implementation while identity approves access policies and reviews logs. In higher-risk settings, such as agentic workflows touching production data, the identity team should also require stronger proof of workload identity, stricter JIT issuance, and explicit audit retention. That aligns with the NHI lifecycle emphasis in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and with the control expectations in OWASP Top 10 for Agentic Applications 2026.
The biggest edge case is when a platform team owns both request mediation and approval logic. That setup is convenient, but it often weakens separation of duties and makes access reviews superficial. NHIMG’s breach analysis on 52 NHI Breaches Analysis shows why this matters: once a proxy becomes the governance authority, it is easy to filter traffic while missing the lifecycle and revocation gaps that actually create exposure.
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 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | Agentic runtime risk makes static MCP access models insufficient. | |
| CSA MAESTRO | MAESTRO covers governance and operational separation for agentic workloads. | |
| NIST AI RMF | AI RMF governance is relevant to ownership, accountability, and oversight. |
Assign clear accountability for agent access, monitoring, and revocation decisions.
