Securing MCP pipelines for an ad group

Context

A global advertising group had moved fast on AI tooling. Over eighteen months, teams across three business units had wired AI assistants to internal data systems using Model Context Protocol connectors, each connecting a model to live campaign data, audience segments, and billing records. No central register existed. The security team had no visibility into which connectors were running, what credentials they held, or when they had last been reviewed.

The CTO’s concern was not theoretical. The organisation processed audience data for large consumer brands, which created both contractual and regulatory sensitivity around how that data could be accessed through AI systems. When an internal red-team exercise flagged that a single compromised connector could reach audience records across multiple clients, the decision was made to bring in external expertise.

Risk

• Over-scoped connector credentials creating a wide blast radius. An audit of the connector estate found that the majority of connectors held credentials with broader data access than their advertised tools required. A connector configured to serve campaign-performance queries held read access across the full audience database. This meant a single confused-deputy incident, an agent being steered by injected content to call a connector, could retrieve data far outside the intended scope.
• Tool-description integrity not monitored. Connectors were deployed from a shared internal registry with no change-control gate on tool descriptions. An attacker able to modify a connector’s tool description could embed adversarial instructions that the model would read as legitimate capability at discovery time, before any user request was made.
• Rug-pull exposure through untracked connector versions. Several connectors auto-updated without requiring re-approval. Trust decisions made at onboarding had no expiry and were not tied to a specific version. A connector approved in month one could be running a materially different version with different behaviour in month twelve, with no one aware.

Engagement

We ran a twelve-week engagement structured in three phases: threat modelling, remediation design, and hardening.

• Connector estate inventory and threat mapping. We catalogued every connector across the three business units, recording for each: the exact credential scopes held, the data it could reach as a deputy if the model were steered, the update channel and current version, and whether the tool descriptions had been reviewed for adversarial content. The output was a per-connector threat record covering the four mechanisms: tool-description poisoning, rug-pull, over-scoped credentials, and confused-deputy reach.
• Credential scope reduction. Working with the engineering leads, we redesigned the credential model for each connector. Credentials were re-issued against per-connector minimum scopes. A connector serving campaign-performance queries received read access to campaign data only, with no path to audience records. We tracked and reduced total exposed data egress paths from the baseline audit figure.
• Change-control gate on tool descriptions. We introduced a change-control requirement for tool descriptions in the internal registry. Any modification to a description required a review step before it could be deployed to a running connector, preventing silent tool-description changes whether from a maintainer or from a supply-chain compromise.
• Version pinning and re-approval cadence. Auto-update was disabled for all connectors holding access to client or audience data. Each connector was pinned to a reviewed version, and a quarterly re-approval cadence was put in place to check the current version against the approved baseline.

Outcome

For a deeper look at MCP supply-chain risks and the controls that address them, see our pillar on Agentic AI and MCP security.