AI Agent Platforms and MCP: Executive Briefing

Every Model Context Protocol (MCP) server an organisation connects to an AI agent is at once a supplier, a holder of credentials and a source of instructions, and most boards have never been told how many there are. MCP has become the common way to plug AI agents into business systems: email, code repositories, CRM, ticketing, cloud consoles and databases. Agent platforms, from coding assistants to low-code builders and hosted enterprise agent services, make connecting a new MCP server a few clicks for any employee. This briefing is for directors, executives and CISOs. It explains why the agent platform and connector layer is now a business risk in its own right, the questions to ask, what good looks like, where to invest and a 90-day plan. It complements the Board and CISO Briefing on agent identity, which covers the agents themselves; this page covers the platforms they run on and the connectors they use.

The risk in one paragraph

An agent is only as dangerous as what it is connected to. MCP standardises those connections: a server exposes tools, such as "send email", "query database" or "merge pull request", and data, and an agent platform lets the model call them. The organisation inherits three risks with each connection. First, supply chain: the server's code, often installed from a public package registry, runs with the access it is given, and a malicious update changes behaviour silently. Second, credentials: the server holds or receives tokens and keys to downstream systems, and a weakness in it exposes them. Third, instructions: tool descriptions and tool results flow back into the model, so a poisoned description or a crafted record can redirect the agent. Because platforms make connection easy and the protocol leaves many security decisions to implementers, these risks multiply with every team that adopts agents, often outside central review.

Why this is a board-level issue now

MCP is now industry infrastructure. Anthropic contributed MCP to the Linux Foundation's new Agentic AI Foundation on 9 December 2025, alongside Block's goose and OpenAI's AGENTS.md. The foundation reported more than 10,000 published MCP servers and adoption by Claude, ChatGPT, Gemini, Microsoft Copilot, Cursor and VS Code. Neutral governance makes the protocol a long-term dependency, not a passing experiment.
The ecosystem is lightly vetted. The official MCP Registry, in preview, is a metadata catalogue. Its moderation policy removes malware, spam and illegal content but not servers with security vulnerabilities, and tells consumers to assume minimal to no moderation. It does not host private servers. Curation and approval are left to the organisation. See the MCP Registry and Server Publishing Security Guide.
Incidents are real and varied.
- A malicious npm package, postmark-mcp, added one line in a later version that copied every email an agent sent to an attacker (postmark-mcp).
- A path traversal bug at an MCP hosting service exposed a platform token with reach across thousands of hosted servers (Smithery.ai).
- A fake error report delivered through an MCP connector hijacked AI coding agents (Sentry MCP agentjacking).
- An authentication bypass and default master keys in an AI gateway exposed the keys it held (LiteLLM MCP auth bypass).
- Hundreds of fake agent skills on a public marketplace delivered credential stealers (ClawHub malicious skills).
Governments have set expectations. Joint guidance from the cyber agencies of the US, UK, Canada, Australia and New Zealand, "Careful adoption of agentic AI services" (2026), asks organisations to give each agent a distinct identity, keep a registry and deny unregistered agents, issue just-in-time credentials and favour resilience and reversibility over efficiency. See Careful Adoption of Agentic AI Services.
Platform choice locks in the control model. Whether a platform supports per-agent identities, connector allowlists, approval gates and exportable logs decides what the security team can enforce for years. These are procurement decisions that often happen in business units.

Where the risk sits

Layer	Examples	Typical failure	Control the board should expect
Agent platform	Hosted enterprise agent services, coding agents, low-code agent builders, agent frameworks	Any user can create agents and add connectors; admin roles over-assigned; logs not exported	Platform admin model, publishing tiers and log export assessed before purchase. See Securing the agent platform itself
Local MCP servers	Servers run on developer laptops via package managers	Unpinned packages, servers inheriting the developer's credentials, one-click configuration from untrusted repositories	Approved list, pinned versions, no long-lived credentials in local configuration. See the Local MCP Server Security Guide
Remote MCP servers	Vendor-hosted connectors, internally hosted servers	Weak or absent authorisation, tokens passed through to downstream APIs, broad scopes	OAuth-based authorisation per the MCP specification, audience-bound tokens, minimal scopes. See the Remote MCP Server Hardening Guide
Connector marketplaces and registries	Public registries, skill stores, plug-in catalogues	Typosquatted or malicious servers and skills; trust based on popularity	Private registry or allowlist; trust assessment before approval. See MCP Server Trust Assessment
Gateways	MCP gateways and AI gateways in front of servers	Gateway becomes a single store of every key; default credentials left in place	Gateway treated as a privileged system with its own hardening, monitoring and key protection
Downstream credentials	OAuth tokens, API keys and cloud roles the servers use	Shared, long-lived or user-impersonating credentials	Distinct, short-lived, least-privilege credentials per server and agent

What the protocol does and does not do

Leaders are often told that "MCP is secure" or that "MCP has no security". Neither is right. The specification, latest revision dated 28 July 2026, sets rules but leaves key choices to implementers.

The MCP specification	What it means for the organisation
Makes authorisation optional; where HTTP servers implement it, they should follow the OAuth 2.1-based authorisation section	A server without authorisation is allowed by the protocol. Policy must require it for remote servers
Forbids token passthrough: servers must not accept tokens that were not issued for them	Ask suppliers to confirm compliance; passthrough breaks audit trails and controls
Requires tokens to be bound to the intended server using the resource parameter (RFC 8707) and audience validation	A token stolen from one server should not work on another, if implemented
Tells clients to treat tool annotations as untrusted unless the server is trusted, and recommends a human in the loop for tool calls	Labels such as "read only" are claims, not controls; approval gates must be enforced by the platform
Says local servers using the stdio transport take credentials from the environment rather than the authorisation flow	Local servers usually inherit whatever the developer's machine holds; that is where secrets leak

The detail sits in the MCP Authorisation Specification Guide and the MCP Security Guide.

Five questions for the board to ask

How many agent platforms and MCP servers are in use, and who approved each one? A credible answer is an inventory that includes developer machines and business-unit platforms, with an owner per server.
Can an employee connect a new MCP server or skill without review? If yes, the organisation's supply chain is set by individual choices. The answer should name the allowlist or private registry and how it is enforced.
What credentials do our MCP servers hold, and are any shared, long-lived or borrowed from a person? A server running on an engineer's personal token can do everything that engineer can.
Which agent actions through connectors require human approval, and is that enforced by the platform rather than by the model's instructions? Sending external email, changing code, moving money and deleting data should not depend on a prompt.
If a connector we use were found malicious tomorrow, how fast could we find every agent using it and revoke its access? Ask for the time measured in the last exercise.

Red flags in management answers

"It is in the official registry": the registry does not vet security; listing is not approval.
"The vendor's agent platform handles security": platform defaults rarely enforce the organisation's connector allowlist, approval rules or log retention.
"Agents use the developer's own access": this removes attribution and multiplies the impact of any hijack.
No owner for the MCP gateway: a gateway that holds every key is a crown-jewel system and needs the same care as a password vault.
Inventory from procurement only: most MCP servers are free packages that never pass through purchasing. See the Unsanctioned AI Agents and MCP Servers Guide.

What good looks like

Area	Good practice	Evidence to request
Inventory	All agent platforms, MCP servers, skills and gateways listed with owner, version, data reach and credentials	Inventory extract; see the MCP Server Inventory Template
Approval	New servers and skills pass a trust assessment before use; unapproved ones are blocked by platform policy	Allowlist, block policy and approval records
Identity	Each agent and server uses its own identity; no personal or shared credentials	Percentage of servers on dedicated identities
Authorisation	Remote servers use OAuth with audience-bound, short-lived tokens and minimal scopes; no token passthrough	Supplier attestations, configuration review
Oversight	High-impact tool calls require enforced human approval	List of gated actions and test results
Monitoring	Tool calls logged with agent, user, server and outcome, sent to the security operations centre	Log coverage and alert examples
Response	Playbook to disable a server across all platforms and revoke its tokens	Exercise date and time to contain. See the MCP Incident Response Playbook

Decision guidance for leaders

Small organisations: standardise on one agent platform, allow only a short list of vendor-hosted connectors from suppliers already assessed, and switch off local MCP servers for non-developers. Simplicity beats tooling.
Large organisations: run a private registry or allowlist, place a gateway in front of remote servers for policy and logging, and treat the gateway and platform admin roles as privileged access. See the MCP Gateway and MCP Server Governance Guide.
Build versus buy: internally built MCP servers give control over credentials and logging but need secure development and testing; vendor-hosted servers shift operation to a supplier, which then needs third-party assessment. See the Third-Party AI Risk Guide.

Questions to put to agent platform suppliers

Before a business unit signs for an agent platform or a hosted connector, the board can expect management to have answers to these, in writing.

Question	Why it matters
Does each agent get its own identity in our directory, or does it act as the user or a shared service account?	Decides attribution, least privilege and whether one agent can be switched off alone
Can we restrict which MCP servers and skills users may add, by policy, across the tenant?	Without it, the allowlist exists only on paper
Where are connector tokens stored, who at the supplier can reach them, and how are they revoked?	The platform becomes a store of keys to your systems
Can approval for specific actions be enforced by the platform, independent of the model?	Instructions can be overridden by injected content; platform controls cannot
Which logs are available, at what level of detail, for how long, and can we export them?	Investigations and regulatory evidence depend on tool-call records
How will you notify us of a security incident affecting the platform or a connector, and how fast?	Containment depends on early notice. See AI Vendor Breach Response

Where to invest first

Discovery: find agent platforms, local and remote MCP servers, skills and gateways, including on developer machines and in SaaS tenants.
Allowlisting: a private registry or platform policy so that only approved servers run, with versions pinned.
Credential clean-up: move servers off personal and shared credentials onto dedicated, short-lived, least-privilege identities. See the AI Agent Credential Lifecycle and Rotation Guide.
Enforced approval gates: for external communication, code changes, payments and deletion.
Logging and response: tool-call logs in the security operations centre and a tested route to disable a connector everywhere.

Metrics to track

Number of agent platforms and MCP servers discovered, and the percentage approved with an owner.
Percentage of MCP servers running on dedicated identities rather than personal or shared credentials.
Percentage of remote servers using OAuth with audience-bound tokens.
Number of unapproved server installations blocked each month.
Percentage of high-impact tool actions behind enforced approval.
Time to disable a connector and revoke its tokens across all platforms, measured in exercises.

A 90-day plan

Days 1 to 30: discover platforms, servers and skills; brief the executive team; issue interim rules: no new public MCP servers without approval, no personal credentials in agent configuration.
Days 31 to 60: assess and approve or remove each server found; set up the allowlist or private registry; move the riskiest servers to dedicated, scoped identities; define the actions that need human approval.
Days 61 to 90: send tool-call logs to the security operations centre; run an exercise in which a connector is declared malicious; set platform selection criteria for future purchases; report the metrics above to the board.

Common failure patterns

Trusting popularity: download counts and registry listings stand in for review, as in the postmark-mcp case.
Unpinned updates: servers update automatically, so a safe version becomes a malicious one overnight.
Gateways without hardening: the component that centralises keys keeps default credentials.
Treating tool output as data only: content from connectors can carry instructions that steer agents.
Platform bought by a business unit: security learns of it after agents are live with broad connectors.

Standards and references

How NHI Mgmt Group can help

We provide independent NHI and agentic AI risk assessments, business case development and board briefings, with a focus on the identities and credentials that agents and MCP servers use to act. Our NHI Foundation Level Training Course includes an agentic AI section for security and IAM teams. Contact us to arrange a briefing.

Related NHI Mgmt Group resources: MCP Security Guide · Board and CISO Briefing · Board Briefing: AI Security · MCP Server Security Checklist · Agent Protocols Compared

AI Agent Platforms and MCP Executive Briefing: Connector Risk, Board Questions and First Investments