// AI GOVERNANCE / MCP CONNECTORS
What to Connect and What to Refuse
Short answer. Connect the smallest read scope that lets an agent prepare a defined piece of work. Keep consequential writes separate, reviewable, and owned by a person who can stop them. An AI agent that cannot reach the CRM, product data, or approved claim language is a writing assistant with a subscription. An agent that can reach everything is an incident waiting for a better prompt.
The work lives between those two bad choices. A useful commercial agent needs enough context to prepare a real answer. It should not be able to alter a customer record, pull a company-wide export, approve a discount, or send an email because a sentence buried in a connected document told it to.
That is the access surface in AI Governance for Commercial Teams, the fourth piece in this series. The question is not whether to connect an agent. The question is what specific job the connection serves, what it can return, and what the system is still forbidden to do after it has the answer.
MCP does not make a connector safe
Model Context Protocol makes it possible for a model client to discover and call tools from a service. That is useful. It does not settle the business decision behind the tool.
The current MCP authorization specification puts the mechanics on solid ground when an HTTP server needs authorization. It uses OAuth 2.1, says access tokens must be validated for their intended audience, and explicitly forbids token pass-through to an upstream service. Those are important boundaries. They do not answer whether an agent preparing an account brief needs the ability to see private executive notes, whether it should see every account in Salesforce, or whether it should be allowed to change a deal stage.
Authentication answers who presented a credential. Authorization answers what that credential can do. Governance answers whether the capability should exist at all.
Most teams stop at the first question. They connect a CRM, a drive, and an email system because the demo looks better with more logos. Then the model receives a broad tool called search_everything and a vague prompt such as, “get me ready for this call.” That is not a workflow. It is a request for the agent to decide which data matters, which data it may expose, and which next action is acceptable.
Read, review, and write are different jobs
A good access design separates the jobs before a model enters the picture.
| Job | Useful permission | Permission to refuse |
|---|---|---|
| Prepare an account brief | Read a named account, its approved contacts, current stage, and recent logged activity | CRM-wide export, private notes, ownership changes, record merges |
| Draft customer-facing copy | Read approved claims, current product catalog, and source citations | Publish, change claim status, or treat a draft as an approved source |
| Flag a renewal risk | Read approved product usage and support signals inside a defined account window | Change forecast, discount terms, account tier, or renewal date |
| Prepare a sales follow-up | Read the account brief and approved recent interaction history | Send email, enroll a contact, modify consent, or add a prospect to a sequence |
| Update a commercial record | Produce a proposed field-level change with evidence | Write directly until a named owner approves the change |
The small words matter. A named account is different from the whole CRM. An approved claim is different from an old slide in a shared drive. A proposed field-level change is different from an agent given write access and told to keep the database clean.
RevOps has learned this lesson the hard way. A duplicate merge or ownership change can reroute a live opportunity, break attribution, or erase the reason a rep made a decision. A marketing team has the same problem when an agent writes a product claim from a source it found but nobody approved. The model may sound confident. The record is still wrong.
Refusal is part of the design
Every connector request should produce two lists. The first names what the agent needs. The second names what it cannot touch and why.
For a MarTech research workflow, I would usually connect a narrow, read-only account view; a curated product catalog; the current approved-claims library; and an explicit list of sources the team trusts. I would keep identity administration, billing, compensation, legal holds, deletion tools, production databases, company-wide exports, and unrestricted shared drives out of the path.
That does not mean those systems are forbidden forever. It means they need their own workflow, purpose, owner, and control. A finance agent that prepares a reconciliation is a different thing from a sales-research agent. Giving them the same tool belt because both use a language model is lazy system design.
OWASP calls the failure mode excessive agency. In the 2025 LLM Top 10, it points to excessive functionality, excessive permissions, and excessive autonomy as the root causes. That is a useful way to read a connector inventory. If a tool can do ten things but the agent needs one, reduce the functionality. If it can see every record but needs a few fields, reduce the permission. If it can act after it finds an answer, reduce the autonomy.
Connected data is not trusted instruction
Prompt injection gets more interesting once an agent can read and act. The malicious text does not need to arrive in the chat window. It can sit in a web page, a PDF, a support ticket, a CRM note, a product review, or a document somebody uploaded last year.
OpenAI describes prompt injection as a third party placing instructions in content the model can see, attempting to make it do something the user did not ask for. That changes how a commercial team should handle connected data. A note on an account may be useful context. It is never a valid instruction to export a list, reveal a discount floor, change a contact, or send an email.
The practical rule is simple. Treat retrieved content as evidence to inspect, not authority to act. The agent can quote it, summarize it, and attach it to a proposed decision. It cannot let it expand its permissions or choose a sensitive destination.
This is also why a tool boundary has to survive a model mistake. OpenAI is direct that prompt injection remains an evolving problem and that filtering input alone is not enough. A system should limit the damage even when a model sees misleading content. Separate connectors, narrow scopes, destination controls, and approval before a consequential write do that work. A prompt asking the model to behave is not a control.
The connector review I would require
Before a commercial team enables an MCP connector, the owner should be able to answer these questions in plain English.
- What decision or task needs this data? “Make the agent smarter” does not count. Name the output, the user, and the moment it is used.
- Which exact fields or resources does it need? Default-deny is easier to audit than a broad permission set you hope nobody abuses.
- What is the narrowest read scope? Scope by account, object, date range, collection, or named resource where the system allows it.
- Can the returned content contain untrusted instructions? Assume yes for user-authored, third-party, or web content. The answer changes where the agent may send that content next.
- What happens if the agent is wrong? Separate an answer that can be reviewed from an action that changes a record, sends a message, spends money, or publishes a claim.
- Who can revoke it? Name the owner, document the off switch, and make sure revocation does not require a production incident to justify it.
There is no committee required here. A one-page connector record with those answers is more useful than an AI policy nobody can apply to a real integration. It belongs beside the audit-scope record for the service and the human gate for the action. It also creates the starting point for the next governance surface: the audit log. Six months later, you need to know which connector supplied the data, which scope was active, which model used it, and who approved the action that followed.
What this looks like in a commercial workflow
Say a sales leader wants an agent to prepare a pre-call brief. The useful version reads a named account, approved contacts, open opportunity data, approved product claims, and public company news. It gives the rep a compact evidence packet and a draft agenda.
The agent does not change account ownership. It does not add the prospect to an outreach sequence. It does not pull executive-compensation data from a connected HR folder. It does not write a new customer claim into the approved library. If it finds a conflict, it says so and gives the rep the evidence.
That system can save serious time. It also gives someone a clean place to inspect the work. More importantly, it can be repaired. If a connector returns the wrong record, the team changes the match rule. If a source keeps introducing untrusted or stale copy, the team removes it. If a rep keeps correcting a field, the team moves that field behind a better review step. The model is only one part of that loop.
Good connectors do not make an agent all-powerful. They make it useful enough to do a defined job, then stop.
Frequently asked questions
What is MCP connector security?
MCP connector security is the practice of defining which tools and data an AI agent may reach, for what purpose, and with what authority. It includes authentication, narrow scopes, token audience validation, source trust boundaries, logging, and a separate approval path for consequential writes. A connector is an authorization decision, not a checkbox in an integrations screen.
Should an AI agent have access to a CRM?
Often, but not as a blanket connection. A research agent may need a narrow, read-only view of a named account, approved contacts, deal stage, and recent activity. That does not justify permission to export the whole CRM, read private notes, change ownership, alter stages, merge records, or send messages. Start with a specific job and expose only the fields the job requires.
Why should AI read and write permissions be separate?
Reading information lets an agent prepare work. Writing changes a customer record, sends a message, changes a price, or commits the company to an external action. Those carry different consequences. Keep the write capability separate, show the proposed change as a reviewable diff, and require a named person to approve it when the action is consequential.
How can prompt injection enter through a connected data source?
An AI agent can encounter untrusted instructions in web pages, documents, CRM notes, support tickets, product reviews, or other connected content. The text may look like data to a person but influence an agent that treats it as instruction. Treat returned content as untrusted, keep sensitive destinations outside the same workflow, and require approval before the agent performs a write or shares data.
What should AI agents never access by default?
Do not give a general-purpose agent blanket access to credentials, identity administration, payroll, legal holds, production databases, financial transfers, deletion tools, or an entire shared drive. Each may be appropriate for a dedicated, tightly controlled workflow. None belongs behind an open-ended prompt and a broad connector.
Sources
MCP authorization, OAuth 2.1, token audience validation, and the prohibition on token pass-through: Model Context Protocol, Authorization specification. Excessive functionality, permissions, and autonomy as the roots of excessive agency: OWASP LLM06:2025 Excessive Agency. Current prompt-injection risk and the case for layered, impact-limiting controls: OpenAI, “Understanding prompt injections” and OpenAI, “Designing AI agents to resist prompt injection” (March 2026).
About the author
Jeff Brokaw is a CMO and Certified Chief AI Officer who ships AI in production, not slideware. He works on the commercial systems around AI: access, data, claims, measurement, and the decisions that turn a model into a useful business tool.