Why Repeated Permission Redefinition After Every New AI Tool Addition Is a Governance Architecture Problem

Repeated permission redefinition after every new AI tool addition is a governance architecture problem. For enterprise AI data sources to inherit permissions automatically, access controls must live in a shared infrastructure layer. That layer must inherit source-system permissions, tie requests to user identities, and enforce policy at runtime so teams do not have to rebuild access rules when they add an AI client.

How MCP became the connective tissue enterprises depend on — and why governance wasn't built in

MCP is the standard interface that AI clients use to reach enterprise data, tools, and workflows across major platforms. A server built once can be used by any MCP-compatible client. That changes the work from bespoke integration engineering to configuration. The interface becomes shared infrastructure.

MCP moved to the Linux Foundation’s Agentic AI Foundation in December 2025, with Anthropic, Block, and OpenAI as co-founders. Google, Microsoft, AWS, Cloudflare, and Bloomberg were supporting backers. That cross-vendor footing makes implementation decisions consequential across an organization’s stack. The protocol standardizes discovery and invocation while leaving unspecified who may use a tool, under which conditions, or with which audit trail. Those decisions fall to the implementation.

Why the default MCP implementation model produces a governance vacuum

The typical starting implementation connects an AI client to a data source through a service account or API key. The AI then gets access to everything that credential can reach. It is a convenient starting point for a developer testing a connection locally. It is not a per-user permission model. Without added controls, the implementation has no per-user authorization, per-operation logging, or sensitivity label enforcement.

When a shared credential reaches Slack or a file repository, the AI can read every message or document available to that account. The account determines the access boundary for every person using it. A successful connection proves that the client can reach the system, but it says nothing about whether a particular user should retrieve particular data.

Default logging leaves a related gap. It may record that the AI made a request without identifying which user authorized it, which data it retrieved, or what action followed. For organizations subject to HIPAA, GDPR, SOX, or FedRAMP, that log format creates a compliance gap. The system permits actions through a shared identity, then lacks the record needed to explain those actions at the user level.

What happens when this pattern scales across a growing AI stack

When every agent manages its own authentication, credentials spread across environment files, individual servers, notebooks, and team configurations. A key rotation then requires finding and updating every copy. Teams also rebuild tools that already exist elsewhere because those tools are undocumented or invisible outside their original team. Each new deployment leaves teams with another local configuration to keep up to date.

The fictional Continental scenario illustrates this pattern. In the scenario, each GitHub App key rotation breaks IDEs across the fleet. A vendor’s endpoint change from /v1/mcp to /v2/mcp forces manual configuration rewrites that trickle on for weeks without finishing. Every developer laptop holds entries maintained individually. After the move to a centralized control plane, configuration entries drop to approximately 8, and credential rotation becomes a single Vault sync requiring no individual developer action.

The contrast is about where state lives. Local configurations turn a shared change into work for every consumer, while a central control plane provides one place to manage it. The governance version of this problem is harder still. If authorization state also lives locally, teams must reconstruct who has access across scattered tools and logs. Without registries, approval workflows, and audit layers, organizations face obstacles when they move past adopting agents and start to consider giving them write access.

Why do permissions need redefining for every new AI tool?

Permissions need redefining when each integration owns its authorization state instead of inheriting policy from shared infrastructure. Better documentation can make that work more orderly. It cannot remove the need to do it. Runbooks, access reviews, and integration checklists manage the consequences of local permissions, but they leave the underlying placement of authority unchanged.

Even user-scoped authorization can produce this problem. The standard MCP authorization model follows interactive conventions in which an individual decides what may touch their data. In an enterprise, every employee must authorize each server, while security teams struggle to apply the same policy to all those choices. Work and personal accounts can also blur together without a mechanism requiring corporate identity. Individual consent is not the same as organizational control.

Another way to build this puts the authorization decision in the hands of the organization’s identity provider. Administrators define policy centrally, and users inherit server access according to their groups and roles without a separate consent screen for each server. That changes who owns the decision. It does not, by itself, establish every permission needed inside the connected system. Connection authorization and runtime access controls must work together if inherited access is to remain scoped after an agent connects.

What moving authorization upstream actually looks like in the MCP stack

The Enterprise-Managed Authorization extension, or EMA, makes the organization’s identity provider authoritative for MCP server access. Administrators define policy once, and users authenticate with their existing corporate identity. The provider grants or denies access based on group membership, role, and conditional access rules. There is no per-server consent screen to complete. Access decisions are in the identity provider’s admin console, so there is a shared audit trail for connection authorization.

EMA is now stable and is being adopted by Anthropic, Microsoft, Okta, and a growing number of MCP servers. Okta is the first supported identity provider, using its Cross App Access capability. Anthropic has implemented EMA in its shared MCP layer for Claude, Claude Code, and Cowork, and Visual Studio Code has added support. Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase support EMA, with Slack actively adding support.

Runtime enforcement is a separate job. EMA does not inspect MCP traffic after a token is issued, so a gateway must govern what an agent can do once connected. The gateway-plus-registry pattern has tool-level access controls, per-request authorization, and action-level audit logging, and it takes a default-deny posture. A security-scanner agent, for example, can receive only the tools it needs from a server exposing a much larger set. If the agent is compromised, its authorized tool set limits the damage.

Uber’s engineering account describes its MCP gateway as a “policy enforcement point,” showing that this pattern is already used in production. The registry must make that enforcement traceable. Its records need caller identity and session context, tool name, version and schema, inputs, target account, outcome, and the policy evaluations and approvals applied. These records support a concrete question about each action. Who did what, when, and was it permitted.

Why a metadata registry alone does not close the governance gap

A registry can help people find servers without governing their use. The official MCP public registry lets people discover servers, but it has no built-in governance, runtime enforcement, or access control. It is unauthenticated, lacks role-based permissions, and does not record when or how tools are invoked. Discovery is useful, but it is not enforcement. The public registry alone cannot enforce internal allow-lists or prevent developers from connecting to unlisted servers.

A governance layer therefore needs more than server descriptions and connection details. It needs identity binding for each call, runtime controls over permitted actions, and a complete, queryable record of tool invocations. Its registry must also support granular tool filtering, version tracking, and ownership records. Those functions connect discovery to operational responsibility. When a schema changes or an endpoint breaks, policy must remain attached to the tool, and someone must be accountable for it.

How department-specific MCP servers apply this architecture in practice

Department-specific MCP servers give inherited permissions a useful operational boundary. A team’s agents receive only the tools and data they need. A governed registry can give a support agent order-lookup tools while keeping account-modification tools out of its context entirely. Inheritance still needs a defined scope. Giving access to everything automatically would be easy, but it would leave access without the limits that governance needs.

For RevOps, the scope should include CRM, account, and external business data that help representatives get ready for calls. Evaluating permissions requires checking whether named scopes separate read from write for every data family, with workspace admin policy limiting what individuals can grant. Salesforce’s Hosted MCP Servers went generally available in April 2026 for Enterprise Edition and above, handling hosting, authentication, and permissions for AI clients querying and acting on CRM data. Governance beyond that source-specific capability requires a broader layer to govern the other systems a RevOps agent uses.

Engineering presents a different tool surface. Agents may need GitHub or GitLab, Jira or Linear, Datadog or Sentry, and cloud infrastructure tooling. Cursor for Slack lets teams give tasks to coding agents inside Slack and connects to the workspace’s channels, messages, and files. That convenience does not make every engineering tool appropriate for every agent. The same rules for filtering apply to both collaboration data and development tools.

Support offers a narrower example. Intercom’s MCP server can search and fetch conversations, contacts, companies, and Help Center articles for ticket triage. A support deployment can give agents that read-oriented subset without giving them write access to account records. The scope belongs in the server and governance definition, rather than in a fresh permission exercise whenever the team adopts another AI client.

What organizations need to evaluate when choosing a governance layer for MCP

Evaluation starts by checking whether the layer automatically syncs and inherits access controls from source systems, or requires those permissions to be recreated for AI. This distinguishes permission inheritance from centralized permission re-entry. The distinction applies when evaluating connections to systems such as document management platforms, Salesforce, or data warehouses. A connector count cannot answer it. Neither EMA support nor a hosted MCP server, on its own, establishes automatic source-permission synchronization across those systems.

The named options serve different roles rather than forming an interchangeable vendor shortlist. Okta’s EMA support addresses centrally managed server access, while Salesforce’s hosted servers address connections to CRM data. A gateway supplies runtime enforcement, and the public registry supplies discovery. Evaluation must match the requirement to the component. Otherwise, an organization can buy a useful part and mistake it for the whole governance layer.

The next questions concern attribution and scope. Is every call bound to a specific user identity and session, or does it run under a shared service account. Can administrators permit only selected tools on a server, or does connection access expose everything. Can security teams query one complete audit record for all connected servers, with the inputs, policy decisions, and outcomes. A shared login and scattered server logs do not provide that level of accountability.

Ownership and versioning test whether the architecture absorbs change centrally. When an endpoint or schema changes, does the governance layer manage that change, or must every consumer update independently. Teams should be able to keep using their permissions, controls, and audit trails when they add another AI client or model without taking on another migration project.

The final test is expansion across teams. A governed MCP layer must combine synced source permissions, scoped team interfaces, and a versioned registry of skills and tools that can serve different agents and chat surfaces. Adding another tool should reuse those foundations. That is how AI adoption compounds instead of fragmenting into separate islands of context, permissions, and guardrails.