MCP rollout: what should IAM and security teams govern first?

TL;DR: Rolling out MCP is really an API governance problem with a new transport layer, not a greenfield protocol project, according to Archestra, because teams still have to decide which internal APIs, users, scopes, logs, and approvals are allowed into AI sessions. The practical risk is not the protocol itself but unmanaged access, audit gaps, and weak gateway controls.

Editorial analysis by NHI Mgmt Group, based on content published by Archestra: “So you're the 'MCP person' at your company now”.

Key questions

Q: What should security teams govern first in an MCP rollout?

A: Start with API ownership, data sensitivity, and the destructive actions each endpoint can trigger.

Q: Why does MCP gateway governance matter for access control decisions?

A: Because the gateway is where tool invocation is actually approved or denied, and that decision sits closer to runtime action than the original login.

Q: How should teams handle authorisation beneath an MCP layer?

A: They should treat the MCP server as a translation layer, not a trust boundary.

Practitioner guidance

• Inventory candidate APIs before building anything List the internal APIs that users want AI to act on, then record the owner, current auth model, destructive endpoints, and business impact of a bad call.
• Place every MCP server behind a gateway Use a single gateway for unified auth, structured audit logs, namespace filtering, credential injection, and version pinning instead of exposing servers directly.
• Delay delegated auth until the base model is stable Get SSO and audit working first, then evaluate on-behalf-of flows and downstream scopes once the organisation has a reliable evidence trail.

Bottom line: MCP rollout should be governed as an access and audit problem, with API ownership and sensitivity defined before any server goes live.

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →