Model Context Protocol (MCP) makes it easier for AI clients to discover and use external tools, resources, and prompts through a shared protocol. That interoperability is valuable precisely because it reduces custom integration work. It also creates a governance question: when connecting a new server can expose new data and actions to an AI client, organizations need a controlled way to decide which servers are trusted, what they may access, and how their capabilities are reviewed over time.
MCP governance is a cross-platform integration problem, not one interchangeable exam objective. AIP-C01 assesses secure generative-AI tool integration and operations on AWS; Amazon Bedrock AgentCore Gateway is one way to expose and control tools through MCP-compatible endpoints. AI-103 tests agent and tool integrations within Microsoft Foundry, including authorization and oversight of tool access. In either case, protocol support only means that a client can discover and invoke an agreed interface. It says nothing by itself about who owns the server, who is allowed to call a tool, which data leaves the organization, or whether a new version quietly exposes broader capabilities.
A protocol standardizes communication, not organizational approval
An MCP-compatible server can describe capabilities in a predictable way, but protocol compliance does not answer whether the organization should permit that server to handle its data or actions. A server still has an operator, software supply chain, deployment location, authentication model, permissions, logging behavior, retention policy, and update process.
The agentic AI engineering control plane should separate technical compatibility from admission. An approved server inventory can record owner, purpose, environment, trust tier, allowed identities, data classifications, and review status; clients then resolve tools from that controlled set instead of letting users silently attach arbitrary servers to sensitive workflows.
Server identity and code provenance are foundational controls
Before evaluating individual tools, an organization needs confidence about which server it is talking to and which software is running there. Endpoint allowlists, certificate validation, deployment controls, signed artifacts, dependency management, and change records can all contribute. Local MCP servers require equal scrutiny because local execution can access files, credentials, and network resources that a remote service cannot.
Ownership matters as much as location. A server maintained by an internal platform team may have a different review path from a third-party server downloaded from a public repository. Governance should record who can update the server, how quickly changes propagate, and whether a new version can alter exposed tools without a fresh approval.
Tool catalogs are an authorization surface
Tool names and schemas tell the model what operations are possible. Governance should classify those operations by consequence: read-only lookup, data creation, modification, deletion, external communication, financial effect, privilege change, or infrastructure control. A generic “MCP access” permission is too coarse when one server exposes capabilities with radically different impact.
Microsoft Foundry agents can connect to remote MCP servers through project connections and managed toolboxes. Teams can restrict available tools and require approval for invocations with sensitive effects; an approval request identifies the proposed tool and arguments before execution. That helps make the agent’s request reviewable, but it does not validate the external service’s code, its authorization rules, or the correctness of returned data. An approved MCP integration still needs server ownership, identity scoping, a change-review process for tool catalogs, and records connecting the human or agent principal to a backend operation.
On AWS, Amazon Bedrock AgentCore Gateway creates an MCP endpoint that can expose targets such as Lambda functions or APIs as tools. Gateway configuration separates inbound authorization to the gateway from outbound authorization toward the target service. That distinction matters when an agent acts on behalf of different users: sharing one gateway endpoint should not mean sharing unrestricted access to the same records. A production design should make the target’s authentication mode explicit, classify tools by read/write consequence, constrain parameters in the backend, and re-review the integration when tools or target permissions change.
Well-scoped MCP tool contracts make policy easier to enforce. Read and write behavior can be separated, parameters can be constrained, and dangerous operations can be given explicit names rather than hidden behind a multifunction command. Tool annotations or metadata can inform user interfaces and risk handling, but servers must still enforce authorization independently of what the model or client believes the annotation means.
Least privilege applies to both client identity and server credentials
An AI client should not automatically receive every capability available to the human user, and an MCP server should not run with a single broad credential simply because doing so simplifies integration. Scope should reflect the task, environment, and identity.
Where the architecture supports delegated authorization, the server should receive the narrow authority needed for the requested operation rather than a reusable administrator secret. Service accounts should be segmented by environment and purpose. High-impact operations can require stronger authentication, step-up approval, or separate credentials from routine reads.
The critical property is that model choice never creates privilege. The model may select a tool, but the server and surrounding application decide whether the active principal can use that tool against the requested target.
Connection approval should consider data flowing in both directions
Governance discussions often focus on what a tool can modify. Read access can be equally sensitive. An MCP server may expose source code, customer records, tickets, files, secrets, or operational telemetry to the model. That data can then appear in prompts, logs, memory, or other tool calls.
Admission reviews should therefore map data flow: what the server can read, what the client sends to it, what the model receives back, where those results are logged, and whether outputs can be forwarded to another capability. Classification and residency rules may make a technically harmless read tool inappropriate for a particular model endpoint or environment.
Prompt injection can exploit trusted tools through untrusted content
MCP expands the set of actions an influenced model can attempt. If retrieved documents or tool results contain malicious instructions, the model may try to invoke another MCP tool with attacker-chosen arguments. Indirect prompt injection therefore has to be contained by server admission, least privilege, argument validation, and authorization at execution rather than by trusting the model to ignore malicious text.
The defense is not to assume approved servers make model behavior trustworthy. Tool servers should validate all inputs, constrain destinations, enforce authorization, and reject operations outside policy. Clients can require human approval for consequential tools and expose only the subset of tools relevant to the current task. Content provenance should remain visible across tool hops so data from an untrusted source does not become “trusted” merely because an internal tool returned it.
Version and capability drift require continuous inventory
An approved server is not static. A software update can add tools, broaden parameters, change authentication, modify data retention, or introduce a new dependency. If the governance record says “server approved” without tracking version and capabilities, the actual risk can drift far away from the reviewed state.
Organizations can snapshot tool catalogs, schema hashes, server versions, and deployment identifiers. Material changes can trigger re-review. Automated inventory can flag newly exposed write operations or tools whose descriptions and schemas changed unexpectedly. This is especially important in desktop or developer environments where servers may update more frequently than centrally managed production services.
Observability should connect model intent to server execution
Operational traces should make it possible to reconstruct which user request led to which model proposal, which MCP server and tool were selected, which arguments were validated, which identity was used, what policy decision occurred, and what result came back. Logging only the final chat response loses the evidence needed to investigate tool misuse.
Sensitive values should be redacted appropriately, but trace correlation still needs stable identifiers. Security teams should be able to identify unusual tool volumes, repeated denied calls, access to atypical resources, and new server connections. The same telemetry helps reliability engineering distinguish a model-planning problem from an MCP transport error or a downstream service failure.
Enterprise catalogs can make approved capability easier than shadow capability
Governance succeeds when the supported path is practical. A curated catalog of reviewed MCP servers, documented ownership, standard authentication, reusable deployment patterns, and transparent approval criteria can reduce the incentive for teams to connect unreviewed local integrations.
AI governance turns the MCP catalog into an accountability system by assigning a business owner, technical owner, risk tier, permitted data classes, approved environments, incident contact, and review date to each integration. Those fields support review, revocation, and incident response instead of leaving the catalog as a marketing list of available tools.
Connecting a server should not mean handing it a broad credential that every later tool invocation can reuse without context. Enterprise designs should prefer authorization that is explicit about audience, scope, user, and lifetime. Tokens intended for one service should not be forwarded to another merely because both participate in an agent workflow.
The current MCP specification continues to evolve around authorization and related security behavior, so governance should track protocol release versions rather than treating “MCP” as one timeless implementation. A platform team can document which specification versions and authorization patterns are supported, test client/server compatibility, and block configurations that depend on deprecated or unsafe assumptions.
Every approved integration needs an off switch. Teams should know how to disable a server, revoke its credentials, remove it from client catalogs, identify which users or agents invoked it, and determine which data or actions were involved. A third-party incident may require rapid containment even when the AI client itself is healthy.
Inventory makes that response possible. If server ownership, deployment, credentials, clients, and tool catalog are recorded, responders can scope exposure quickly. If teams only know that “some agents use MCP,” containment becomes a manual search across desktops, repositories, and prompts at the moment speed matters most.
MCP governance should preserve interoperability without inheriting blind trust
Standard protocols create leverage by making tools portable across clients and models. The same portability means that authorization and governance cannot be assumed to live in one vendor-specific integration. Organizations need controls that travel with the capability: approved server identity, narrow tool contracts, least privilege, data-flow awareness, version tracking, deterministic enforcement, and auditable execution.
Client-side policy is useful too. An enterprise client can display which server is supplying a capability, require confirmation before first use of a new server, and show material changes to permissions or tool sets. Visibility helps users understand when an apparently familiar agent has gained a new route to data or action.
When those controls are present, MCP can reduce integration friction without weakening accountability. A model can discover and invoke standardized capabilities, while the surrounding system still answers the questions that matter most in production: who is allowed to do what, against which data, under which policy, with what evidence, and with what response when the boundary is crossed.
