Notifications
Clear all
Topic starter
18/08/2026 2:31 pm
TL;DR: Enterprise-Managed Authorization stabilises a centralised OAuth pattern for MCP so enterprises can authorise users through the IdP once instead of repeating consent for every server, according to Obot. That shifts the problem from per-server friction to gateway and policy governance, because coarse-grained access still needs tool-level control and auditability.
NHIMG editorial — based on content published by Obot: Enterprise-Managed Authorization (EMA) and MCP governance
By the numbers:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope.
Questions worth separating out
Q: How should security teams govern MCP access after EMA is introduced?
A: They should split governance into two layers.
Q: Why do repeated OAuth consent screens become a governance problem for MCP?
A: Because users eventually look for faster paths, and those workarounds create inconsistent approvals, untracked exceptions, and unclear ownership.
Q: What breaks when tool-level policy is pushed into the identity provider?
A: The IdP becomes overloaded with decisions it is not designed to handle, such as per-request tool access, logging requirements, and step-up checks.
Practitioner guidance
- Map the authorisation boundary first Separate the decision to let a user reach an MCP server from the decision to let that user invoke a specific tool.
- Put tool-level enforcement in a gateway Use a gateway or policy layer for logging, observability, step-up verification, and request filtering.
- Validate IdP compatibility before rollout Test dynamic registration, token exchange, and enterprise support across the client, IdP, and MCP server stack.
What's in the full article
Obot's full article covers the operational detail this post intentionally leaves for the source:
- How the EMA token handoff works across client, IdP, and MCP server support
- Where Dynamic Client Registration creates compatibility gaps with enterprise identity providers
- How the gateway layer handles tool-level policy, audit, and observability
- Which current clients and identity providers support the extension in practice
👉 Read Obot's analysis of enterprise-managed authorization for MCP →
EMA for MCP: what changes for enterprise identity teams?
Explore further
18/08/2026 3:18 pm
EMA is a governance improvement, not a complete MCP identity model. Centralised authorisation reduces OAuth sprawl, but it only resolves the first question in the access chain: whether a user may reach a server. Fine-grained tool permissioning, auditing, and request-level control still sit elsewhere, which means identity teams must treat EMA as one layer in a broader control stack, not as the control stack itself.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- OAuth-connected exposure is already common enough that 38% of organisations report no or low visibility, which is why centralised authorisation without governance boundaries can create a false sense of control.
A question worth separating out:
Q: How do teams decide who is accountable for MCP server access and tool use?
A: Accountability should follow the control layer. Identity teams own user and group authorisation at the IdP, platform teams own gateway enforcement and observability, and application owners own the permissions exposed by the server. If those roles are not written down, no one can explain why a request was allowed.
👉 Read our full editorial: Enterprise-managed authorization changes MCP identity governance
