An assistant might search a policy library, inspect a customer record and prepare a message through three different connectors. Those connections serve different purposes and expose different risks. A useful policy excerpt does not authorise a customer-record change, and a message tool should not receive a document-search credential because both happen to sit behind MCP.
The practical question is what each connection can read, disclose, execute or change. Protocol compatibility does not answer that question. The following connector matrix is a proposed operating design, not a certification that the connected servers are safe or that an agent can independently decide which organisation to trust.
Classify capabilities before assigning trust
Start with the operations actually exposed by each server. A connector advertised as a search integration may also list files, download attachments or create records. Record the available operations and decide which ones the workflow needs. Remove or deny the rest where the implementation supports that restriction.
Separate remote data access from local program execution. A local server can run software on the machine or host where it is started, which needs a different review from reading a permitted remote document. MCP security guidance discusses risks around local server execution and the need to consider restricted execution environments. A friendly tool description is not an assessment of the software being launched. Source: MCP security best practices
Describe trust in concrete terms: approved owner, reviewed deployment, permitted records, allowed fields and operational permissions. Avoid a single high or low trust score that obscures these separate facts. A well-maintained server can still have credentials broader than this workflow needs.
Keep returned evidence below task authority
A search result may contain a policy, a customer request or instructions addressed to someone else. Its content should inform the task only within the approved workflow. It cannot assign a new user role, approve a mutation or change the destination for private data.
OWASP identifies indirect prompt injection through external content, including websites and files. It also notes that retrieval does not fully mitigate the problem. That is a reason to enforce the task boundary outside the model as well as instructing the assistant about untrusted material. Source: OWASP prompt injection
For example, a retrieved policy draft might say that the assistant should export all related accounts to a new destination. The approved task was to answer one service question. The application should reject the export regardless of whether the assistant interprets the text correctly. The document can remain evidence of what the draft says without becoming execution authority.
Connector trust matrix
Use this complete proposed matrix for an assistant preparing an internal service response. Replace the fictitious connector names with the actual server and deployment identities, and retain a separate decision for every capability.
| Connector and purpose | Permitted capability and data | Credential and identity review | Execution or release boundary | Expected exception outcome |
|---|---|---|---|---|
| Policy library search | Search approved published policies; return excerpts with version and source reference | Confirm server owner, intended credential audience and permitted library scope | Returned text can inform a response but cannot alter the task or grant access | Missing or conflicting policy versions hold the affected answer |
| Assigned-account lookup | Read permitted account fields for the authenticated actor | Confirm access is checked for each record and excluded fields stay excluded | Lookup cannot authorise account updates or broaden searches | Unassigned or ambiguous record returns a hold without private details |
| Record-change proposal | Prepare a target, field, value and evidence reference without executing | Separate allowed operation from broad upstream credentials; identify responsible owner | Application validates the field and requires an approval bound to the exact proposal | Unsupported field, missing approval or changed payload is rejected |
| Record-change execution | Perform an approved operation against the current record version | Verify actor, tool service identity, token audience and restricted scope | Trusted application decides whether execution is permitted and verifies the result | Conflict or unavailable verification produces an explicit unresolved outcome |
| Internal message preparation | Draft an approved audience-specific message | Confirm recipients and data accessible to the tool; no credential reuse across services | Drafting does not send; release requires the defined recipient and content checks | Unknown audience or sensitive content remains an unsent draft |
| Optional local document converter | Convert approved fixture formats in a restricted environment | Review executable source, deployment, file access and network needs before enabling | No access to unrelated files or credentials; no arbitrary commands from returned text | Unexpected file path or unsupported format is rejected |
For each row, attach the server identifier, deployment version, operational owner, credential owner, allowed operations, permitted records, field exclusions and date of the last review. Record where a restriction is enforced: server, gateway, downstream service or application. A restriction written only in the matrix is an unimplemented requirement.
Run these synthetic acceptance tests before enabling the proposed workflow: one permitted lookup with a single published policy; no matching policy; two contradictory policy versions; an account reference outside the actor's scope; an execution request without its exact approval; and a retrieved fixture telling the assistant to change the task or disclose credentials. Use fake records and tools that record attempted calls without sending messages or altering real systems.
For every test, capture the expected disposition, connector called, permitted data returned, action requested, application decision and observed outcome. Check the boundary even if the assistant gives a sensible answer. If a disallowed request reaches an upstream service, identify the enforcement gap before release.
The matrix is accepted when every needed operation has an owner, implemented restriction and tested exception path. New server operations or changed credentials reopen the relevant row; an earlier approval does not automatically cover a larger capability set.
Restrict credentials to the intended service
MCP's security guidance explicitly forbids token passthrough that accepts client tokens without proper validation and forwards them downstream. It also discusses scope minimisation. These are protocol and credential concerns; they do not by themselves implement the business-approval boundaries in the proposed matrix.
Have the integration owner document which token is intended for which service, how the server validates it and what downstream access is required. Keep secrets outside prompts, returned documents and broad diagnostic logs. If a connector needs an elevation for a privileged operation, review that particular operation and scope rather than giving every connection the largest available permission set.
Also distinguish a session identifier from authenticated authority. A resumed connection or familiar server name is not sufficient evidence that the current actor may access a customer record. The implementation must enforce the relevant identity and access checks at its trusted boundaries.
Work through a cross-connector request
In a hypothetical normal case, the assistant finds a published response policy and one permitted account record. It prepares an internal reply with source references. No account change is requested, and the message remains a draft until the defined release check. Each connector performs only its assigned role.
In an ambiguous case, the policy library returns a published document and an undated draft that disagree. The assistant reports the conflict and holds the affected recommendation. It does not treat the connector's confidence or the document's stronger wording as evidence of authority. The policy owner resolves which version applies.
In a duplicate case, two connectors return the same record reference with different update times. Preserve their provenance and verify the authoritative current record before proposing a change. Two results are not necessarily two customers or two independent confirmations. If the current source is unavailable, keep the proposal unresolved.
Distinguish requested tools from completed actions
OpenAI's function-calling guide separates the model's tool request from the application executing the function and returning its output. Use that distinction in status messages and review records. A connector invocation may request a change, be denied, fail or complete; the assistant should report the observed outcome. Source: OpenAI function calling
This article's matrix covers differences between connected servers and capability types. The narrower read-versus-write design asks how to enforce those operations inside a particular record workflow. Keeping those decisions separate gives reviewers a useful inventory without assuming that one control solves every boundary.
FAQ about unequal trust across MCP servers
Does using MCP mean every server follows the same access policy?
No. Review each implementation, deployment, credential scope and permitted operation. Protocol support is not evidence that the server enforces your organisation's record or approval rules.
Can an approved search result approve a tool call elsewhere?
Not under this proposed design. The search result is evidence. A trusted application checks the separate action permission and any required approval against the exact target and payload.
What happens when a connector adds a new operation?
Reassess the affected capability and credential scope before enabling it for the workflow. Update its matrix row and exception tests. Do not assume that approving the original search operation also approved later writes or local execution.
If your business needs help defining this process, explore Custom AI agents, the wider AI automation services, and our custom-agent workflow guide. The agents and automation comparison and custom AI agent glossary explain the terms. To discuss your records and approval rules, get in touch.