MCP Toolkit: Contract Terms in the Context of MCP Deployment

Posted
By and

Before reading the first three installments of Pillsbury’s MCP connector series, you may have thought MCP-connected agentic architecture was too complicated to understand. But now that you have wrapped your mind around what MCP connectors are, what legal and operational risks they pose, and how to practically mitigate those risks, you may feel ready to deploy them in your organization. But not so fast…

As we have discussed previously, MCP connectors provide a standardized way to connect AI models to external systems, allowing for easier proliferation of agentic AI. That proliferation spawns a constellation of new contractual and operational relationships that require careful risk allocation via your contracts.

For many clients, the MCP question arrives mid-deployment. An agent is already operating, or a vendor has proposed adding MCP connectivity to an existing relationship, and the contractual framework does not yet contemplate agent interaction through an MCP connection. You must adapt the contract to account for the new MCP-enabled reality.

Below is a “checklist” of legal topics to consider, organized by the various types of contractual relationships that commonly support MCP connectors and AI agents.

The Relevant Parties
Four potential participants inform the contract structure for an MCP-connected agent:

  • The User. The end user who prompts the tool to perform a task or action, likely part of a larger enterprise that is a customer of the AI tool providers.
  • The Model (or Agent) Provider. The vendor whose model reasons, plans and decides which tool to call (e.g., the foundational model provider or the developer of the agent).
  • The MCP Connector Provider. The vendor that publishes the specific MCP connection and operates the integration layer. At this stage of MCP proliferation, this is most often the same vendor as the model provider. Less often, it could be the resource owner or another third party.
  • The Resource Owner. The system whose data or functions the agent reaches into (e.g., a SaaS application, a database, an internal system, a market data feed).

The sections below provide a guide for potential key issues to address in each contractual relationship relevant to MCP connectors and AI agents.

Customer Concerns
An enterprise customer may sign contracts with the model provider, with the connector provider, and with each resource owner. Internal policies cover the customer’s own users. As an enterprise customer, the tools should work as configured (including protecting data and access rights), the users should comply with any pass-through requirements, and the resource owners should grant sufficient rights to use the tools. Consider the following issues:

  • Connector Inventory and Approval Rights. Over-permissioned access is a key risk of MCP connectors. The customer should retain control over which connections are enabled, and the ability to disable the connections. If the vendor offers an open marketplace of potential connections, the enterprise customer should ensure that access via the marketplace does not bypass the customer’s vendor risk management process.
  • Data Usage and Residency. The use of an AI agent will not relieve the customer of its general data-related obligations. The customer could require each provider to take measures needed to meet the customer’s internal and regulatory data use and storage obligations.
  • Confidentiality and IP Ownership of Agent Outputs. Standard SaaS contracts often say the customer owns its data. Agent outputs blend customer inputs, model contributions and content pulled from resource owners. The ownership terms should account for that blend rather than assume an input-output model that no longer fits. In many configurations, the model sees content pulled from multiple resource owners. That context is confidential information of multiple parties simultaneously. The contract needs to address who retains confidential information, for how long, and whether the provider may use it for any purpose beyond serving that inference.
  • Performance Obligations. If the services are intended to function in a certain way, the contract should say it. Most importantly, define the unit of performance for the agent—is success measured by outcomes, tool calls, availability or some other metric? Terms that support effective performance may include service levels, warranties and detailed scope descriptions that include room for improvement and evolution of the services.
  • While the customer bears responsibility for provisioning access appropriately, the tool and resource providers bear the responsibility to keep the architecture safe. At a minimum, documentation should explain how the systems are kept secure, and the contracts should allocate responsibility for breaches. The connector layer holds credentials to other systems, and breach notification should trigger upon compromise of those credentials, not just compromise of data.
  • Audit and Inspection Rights. The customer needs the ability to inspect the control plane, decisioning and backlog of the customer’s own activity. Transparency is key for the customer to meet its audit requirements and those of its regulators.
  • Commercial Terms. The customer likely bears the cost of use of the agent and the end resource—but the cost model for both must contemplate agent usage of a connected tool, which is fundamentally different from a user leveraging that tool. For example, the user may require more storage from the model provider to hold the context necessary for tool calls, or the agent may call the tool more often and more quickly than was contemplated for an end user.
  • Indemnification Scope. Standard IP indemnities written for SaaS do not always apply to model outputs or agent-initiated actions. Customers should press for clarity on what is covered (e.g., model output infringement, connector misuse, security incidents involving connector credentials, unauthorized writes initiated by the agent).
  • Limitation of Liability. Liability provisions for SaaS are sized for a service that did not initiate actions. The customer should consider whether adjustment is necessary to account for things like unauthorized data access via an agent, unauthorized writes to a resource owner’s system, and breach of confidentiality through context propagation.
  • Acceptable Use of the Agent. Internal policies should define what employees can and cannot do with the agent. End users bear much of the operational responsibility for data governance, security protection and accountability, and policies should be scoped around those concerns. Such internal policies should also support compliance with other agreements: Vendor liability often turns on whether the customer used the service in accordance with the agreement and its own posted policies.

Resource Owner Concerns
The resource owner bears structural exposure from a connection it did not initiate (and may not even have condoned) and that it cannot fully observe. Its existing contract with the customer may have been written for human users, which requires reconsideration. Resource owners also contract directly with the model provider in order to have the “privilege” of being part of the connected infrastructure.

  • Access at Machine Scale. Does the existing license treat an agent acting on behalf of a human as a permitted user, or is it a per-seat license that contemplates only natural persons? Addressing agent traffic directly in the contract language is usually preferable to staying silent. Existing rate limits, fair-use language, and abuse provisions were calibrated for human pacing. The resource owner may need new thresholds, or a new pricing tier, before it will allow agent traffic to continue.
  • Logging and Audit Cooperation. It can be difficult to reconstruct what was accessed, by what system, and why, but the answers to these questions can be demystified if the contracts between end users and model/MCP providers support transparency.
  • Write Scope and Reversibility. If the agent has write permissions, can it create, modify and delete records? Are bulk operations limited? Resource owners may need to work with customers to scope write access narrowly and require change journaling.
  • Content and IP Rights for Extracted Data. What can be pulled out of the resource owner’s system, and where can it go after extraction? Some content carries third-party license terms. Some carries trade-secret protection that depends on access controls. Extraction into a model’s context window may trigger downstream issues that need to be accounted for at the contract level. Because the model/MCP provider is likely serving as a “middleman,” limiting access rights to unencrypted material may make the most practical sense.
  • Resource owners should consider security as a shared responsibility, and the contracts between parties should create a fabric of interwoven security.

The Model and Connector Provider’s Concerns
The model provider is the brain (i.e., runs the agent). The MCP connector is the arms and legs (i.e., the provider supplies the integration layer and the tool definitions the model relies on to execute actions). From the model or connector provider’s perspective, the core concern is control. The provider may operate the agent or connector, but it does not control the customer’s prompts, the customer’s permissioning decisions, the resource owner’s system, the quality of data returned by that system, or the downstream business consequences of an action the customer authorized. Consider the following issues:

  • Customer Configuration and Access Decisions. The provider should make clear that the customer is responsible for deciding which connectors to enable, which users may access them, and what permissions those users and agents receive. The provider may supply administrative controls, but should have contractual protection when it follows authenticated instructions within the permissions granted by the customer, particularly where the customer enabled write access or approved a connector for sensitive systems.
  • Tool Definition Accuracy and Limitations. The provider should commit to reasonable accuracy in its own tool definitions, while disclaiming responsibility for inaccurate, incomplete or changed information supplied by a resource owner or third-party connector. If the resource owner changes an API, data field, permission model or rate limit, the provider needs room to respond without being deemed in breach.
  • Connector Availability and Dependency Carve-Outs. Provider commitments should exclude actions outside of the provider’s control, such as the availability of the resource owner’s application or failure of the hosting service provider. Service levels should measure the parts of the stack the provider actually controls.
  • Acceptable Use of the Agent. The provider should define prohibited uses clearly. The provider’s liability position will often depend on whether the customer used the agent within the agreed scope. The provider should avoid open-ended responsibility for business decisions, downstream reliance or customer-approved actions that depend on customer data or third-party systems.
  • Data Handling for Context, Logs and Outputs. The provider may reserve the right to retain telemetry, security logs and audit records needed to operate, secure and defend the service. Any provision of materials for audits, and any allocation of ownership rights, should preserve proprietary elements of the services.
  • Resource Owner Terms and Third-Party Restrictions. Where third-party content, SaaS terms, data licenses or API terms restrict use, the provider should not absorb those obligations unless it has reviewed and accepted them. The customer should be responsible for obtaining any necessary consents to connect the agent to resources.
  • Indemnities and Liability Caps. Providers will likely accept responsibility for IP claims tied to the provider’s own model or connector technology. The provider is not the insurer of its customers, and thus uncapped or broad liability for third-party resource content, customer data, customer permissioning errors, unauthorized use of credentials supplied by the customer, or agent actions taken within approved permissions must be avoided.
  • Audit, Transparency and Confidentiality. Customers may need logs and explanations to satisfy governance obligations. The provider, however, must protect platform security, other customers’ information, model and system confidential information, and trade secrets. Audit rights should provide transparency sufficient to satisfy customer governance obligations, without requiring intrusive access to proprietary or sensitive provider information.

MCP deployment should not outpace the contracts that support it, and much of the risk comes from failing to thread the relationships together in a cohesive way. The enterprise customer may be the only party with visibility across the contract stack. The above checklist can serve as a starting point for predicting and effectively managing each party’s concerns.

This is the fourth installment in our series on Model Context Protocol (MCP) connectors. The first installment provided a technical primer on MCP architecture. The second installment catalogued the key legal and operational risks. The third installment outlined a risk mitigation framework.

In the next and final installment of our MCP series, we will turn to the governance questions that legal and procurement teams may ask before an MCP deployment moves from architecture diagram to signed paper.

Pillsbury’s MCP Connector Series

Model Context Protocol (MCP) and Connectors: A Primer

MCP Connectors: Legal and Operational Risks

MCP Connectors: Mitigating the Risks of AI Agents in a Connected Architecture