MCP Security and Governance for Enterprise CX

MCP Security and Governance for Enterprise CX

MCP does not create a new class of risk; it changes where existing controls are enforced. The source system still owns authentication and scope, so a connector cannot grant access that system would refuse. What is genuinely new is that an AI layer reads untrusted customer-written content and can act through connected systems, which makes action control and injection handling the two areas deserving most scrutiny.

What Changes and What Does Not

Start with what does not change, because a review that misses this spends its time in the wrong place.

The system holding the data remains the authority on it. An MCP connector authenticates like any other client, using whatever mechanism that system already enforces, and can only expose what those credentials permit. Nothing about the protocol allows an AI layer to read a record the underlying system would refuse to serve. Access control, data classification and residency obligations continue to be enforced where they always were.

What changes is the shape of the client. Instead of an integration making a fixed set of calls defined in advance, you have a layer that discovers capabilities and decides at runtime which to use, based on a question a human asked.

“The future of Customer Experience will not be defined by the applications we buy. It will be defined by the intelligence that connects them.”

That shift is where the governance work actually sits. Not in the protocol, in the non-determinism of the caller.

The Five Controls Worth Specifying

Scope. A connector should expose the minimum resources and tools a use case requires, not everything the system holds. Specify it per connector, document it, review it when use cases change. The common failure is a connector configured generously in a pilot and never narrowed.

Identity. Two models. A service identity with narrow rights is simpler to reason about and gives every user the same view. User-delegated permissions mean answers respect what the asking person may see, usually required where data is segmented by region, brand or role. Delegated is safer in regulated environments and harder to implement.

Audit. Calls appear at the source system as ordinary API traffic and should be captured in the logs your SOC already monitors. Also ask for the AI layer’s own record of which question triggered which calls. The two together make an incident reconstructable. A layer that cannot say what it read for a given answer is not auditable.

Action control. Write operations are the highest-risk surface. Each should be individually enabled, owned and bounded: which action, in which system, under what conditions, at what rate. Creating a case is low risk. Pausing a live campaign, modifying a CRM record or sending an outbound message is not, and should require explicit confirmation.

Residency and processing. Where data is processed and stored, what is retained and for how long, and whether anything trains models shared beyond your tenancy. Get the last in writing. CX conversation content usually contains personal data, which puts this inside your existing privacy obligations.

The Risk Most Reviews Miss

An AI layer in CX reads customer-written text, and some of the people writing it will work out that a system capable of taking actions is reading it.

Instructions embedded in content the model reads, commonly called prompt injection, is a genuine and unsolved industry problem. A ticket, a post or a chat message is attacker-writable input. Treated as instructions rather than data, a system with write access can be steered.

Four mitigations are worth specifying, and no honest vendor will claim the problem is solved.

Treat all connected content as data, never as instructions. This is an architectural property of the layer and worth asking about directly.

Keep write actions behind confirmation. A read-only layer cannot be steered into doing anything, only into saying something wrong. That alone is a large reduction in exposure.

Bound every action. Rate limits, allowed targets, and no action class that can be chained into escalating privilege.

Monitor for anomalous action patterns, as you would any automated account.

Ask vendors how they handle this. The quality of the answer is a fair proxy for the rest of their security thinking.

A Workable Rollout Sequence

Read-only, narrow scope, one or two systems. Prove the answers are useful and correctly scoped before widening. Most of the business value arrives here.

Add systems before adding actions. Breadth of reading is lower risk than depth of writing, and it is where value compounds.

Enable write actions individually. One at a time, each owned, bounded and reviewed after use.

Review scope quarterly. Connectors accumulate permissions the way file shares do. Treat it as an access review.

How Konnect Insights Approaches It

A few design principles are worth stating, with the boundary of what this article covers made explicit.

KRC reads from connected systems through their own authentication and scope. It holds no separate permission model that could grant access a source system refuses. Connected content is handled as data rather than as instruction. Write actions are enabled per connector rather than by default, and run through the system that owns the workflow so the action is recorded where the audit trail already lives. Data residency options cover India, UAE, Saudi Arabia, Germany, the UK and the US, which is usually where the processing and storage question lands for a multi-market deployment.

Beyond those design properties, specific questions about controls, certifications, penetration testing and incident processes belong in a security questionnaire rather than a blog post, and Konnect Insights answers them there. Any vendor making detailed security assurances in marketing content rather than in documentation is doing it in the wrong place.