Unsanctioned AI agents and MCP servers are shadow AI that acts: they run code, call APIs and use real credentials on endpoints and in SaaS tenants that security teams never reviewed. A chatbot that nobody approved can leak what is pasted into it; an agent connected to an unapproved Model Context Protocol (MCP) server can read files, send email and change production systems with the user's own access. This guide explains what counts as an unsanctioned agent or MCP server, where to find them, how to triage what you find, and which controls in identity providers, CASBs and coding tools bring them under governance. It is for security engineers, IAM teams and platform owners who already have a broad shadow AI programme and now need to deal with the agentic part of it.
Key takeaways
- MCP servers are code and credentials, not settings. The MCP specification says tools "represent arbitrary code execution", and a local stdio server runs with the user's privileges and takes its credentials from the environment.
- Configuration files are the inventory. Agents and MCP servers are declared in files such as
.mcp.json,.vscode/mcp.jsonand.amazonq/mcp.json, so endpoint and repository scanning finds more than network logs. - Identity providers hold the other half. OAuth grants to third-party agents, AI meeting bots and remote MCP servers show up as consented applications in Microsoft Entra and Google Workspace.
- Governance means a fast approved route. An MCP registry or allowlist, managed configuration and quick review beat blanket blocking, which pushes use to unmanaged devices.
- Every surviving agent needs an owner and its own identity. Agents left on a developer's personal tokens cannot be attributed, scoped or revoked cleanly.
What counts as an unsanctioned agent or MCP server
An agent or MCP server is unsanctioned when it acts on organisation data or systems without having passed the organisation's approval process, or when it is used beyond the scope it was approved for. Intent is usually good: a developer wants a database tool in their coding assistant, or a manager connects an AI scheduler to their calendar. The problem is the access, not the person.
| Type | Typical example | Where it runs | Credentials it usually holds |
|---|---|---|---|
| Local MCP server (stdio) | Filesystem, Git, database or cloud CLI wrapper started by an IDE or desktop assistant | User's endpoint, as a child process of the client | Environment variables, CLI profiles, SSH agent, tokens in the config file |
| Remote MCP server (HTTP) | Vendor-hosted connector for a SaaS service, or a team's self-hosted server | Vendor cloud or internal hosting | OAuth tokens for the user; sometimes static API keys in headers |
| Coding agent | Terminal or IDE agent that edits code and runs commands | Endpoint, CI runner or cloud workspace | Developer's Git, cloud and package registry credentials |
| Low-code or SaaS-embedded agent | Agent built in an automation or CRM platform by a business user | Vendor platform | Connection credentials owned by the builder |
| Third-party agent app | AI inbox assistant, meeting bot, research agent | Vendor cloud | Delegated OAuth grant to mail, files, calendar |
| Self-built script agent | Python loop calling a model API with tools | Laptop, VM, container or scheduled job | AI provider API key plus whatever keys the tools need |
For the wider picture of shadow AI, including chat tools and embedded SaaS features, see the Top 10 Shadow AI Risks. For the protocol itself, see the MCP Security Guide.
Why MCP changes the shadow AI problem
MCP standardises how hosts (AI applications) use clients to connect to servers that expose resources, prompts and tools. The current specification (version 2026-07-28) is explicit that it cannot enforce its own security principles at protocol level; that is left to implementers. Four properties matter for governance:
- Authorisation is optional: the specification marks authorisation as OPTIONAL. Where it is used over HTTP, servers must publish OAuth 2.0 Protected Resource Metadata (RFC 9728), clients must send a
resourceparameter (RFC 8707) and servers must reject tokens not issued for them. A shadow remote server may implement none of this. - Local servers inherit the environment: stdio implementations "SHOULD NOT" follow the HTTP authorisation flow and instead retrieve credentials from the environment. In practice a local server can see what the user's shell can see.
- Tool descriptions are untrusted: the specification says descriptions of tool behaviour, such as annotations, should be considered untrusted unless obtained from a trusted server. A server can change its tools after approval.
- One-click install is a code execution path: the security best practices state that a client supporting one-click local server configuration MUST show the exact command, without truncation, and require explicit approval, and SHOULD run servers in a sandbox with minimal privileges. Not every client does this, and repository-level configuration files can bypass the user's own choices.
Two further anti-patterns from the specification are common in home-grown servers: token passthrough, where a server forwards a client's token to a downstream API (forbidden: servers MUST NOT accept tokens not issued for them), and broad scopes such as files:* or admin:* requested up front, which the specification lists as a common mistake. OWASP's Top 10 for Agentic Applications (2026) captures the resulting risks as ASI02 Tool Misuse and Exploitation, ASI04 Agentic Supply Chain Vulnerabilities and ASI10 Rogue Agents.
Where to find them: discovery sources
No single source finds everything. Combine endpoint, identity, network and code sources, and reconcile them against your AI register.
| Source | What it finds | What to look for | Blind spots |
|---|---|---|---|
| Endpoint file inventory (EDR, MDM scripts) | Local MCP servers and coding agents | MCP configuration files: .mcp.json, .vscode/mcp.json, ~/.copilot/mcp-config.json, ~/.claude.json, .amazonq/mcp.json and equivalents for other tools; server command, args, url and env values | Unmanaged and personal devices |
| Endpoint process telemetry | Servers actually running | Package runners and interpreters spawned by IDEs or AI desktop apps; new listeners on localhost | Short-lived processes if sampling is coarse |
| Source repositories | Shared, team-level configurations | Committed MCP configuration files, agent definitions, AI provider keys | Private repos outside the organisation |
| Identity provider | Third-party agents and remote MCP servers using OAuth | Entra enterprise applications with user consent; Google Workspace Accessed apps list with user counts and scopes | Apps using API keys rather than OAuth |
| CASB or SSE cloud discovery | AI services and remote MCP endpoints in traffic | Generative AI app categories, traffic to model provider APIs, unknown hosts receiving long-lived connections | Traffic off the corporate path |
| SaaS audit logs | Agents built in low-code and SaaS platforms | New connections, flows and agents; connectors owned by individual users | Platforms without audit APIs |
| Secrets scanning | Script agents and self-hosted servers | Model provider API keys and tokens in code, notebooks and config | Keys stored only in memory or vaults |
| Finance and procurement | Paid tools bought on cards | AI subscriptions and API billing on expenses | Free tiers |
Many coding tools also emit usage telemetry. For example, Claude Code can export OpenTelemetry events, and setting OTEL_LOG_TOOL_DETAILS=1 adds MCP server and tool names so you can see which servers are actually used. The Shadow AI Discovery Guide covers discovery techniques in more depth.
Triage: how to rate what you find
Rate each discovery on what it can do, not on what it was meant to do. A read-only documentation server and a server that wraps a cloud CLI with administrator credentials are both "an MCP server".
| Factor | Lower risk | Higher risk |
|---|---|---|
| Actions | Read-only, retrieval of public or internal reference data | Writes, deletes, sends messages, runs shell commands, deploys |
| Credentials | Per-user OAuth with narrow scopes and audience-bound tokens | Static API keys, personal access tokens, cloud admin profiles, tokens in config files |
| Data reach | Public data or a single project | Mail, file stores, CRM, source code, production databases |
| Provenance | Official vendor server, pinned version, internal registry | Unknown publisher, lookalike name, unpinned latest package, fetched at every start |
| Untrusted input | Only the user's own prompts | Reads email, web pages, tickets or issues that outsiders can write |
| Where it runs | Sandbox or container with restricted network | Developer laptop with full home directory, SSH keys and cloud credentials |
| Owner | Named, current employee | Unknown, departed or a shared account |
A useful rule: any agent that combines untrusted input, access to sensitive data and an ability to communicate or act externally should be contained immediately while it is reviewed. See the AI Agent Threat Modelling Guide.
Governing agents and MCP servers: the controls
Approved registry and allowlists in the tools
- GitHub Copilot: enterprises and organisations can enable the "MCP servers in Copilot" policy, set an MCP Registry URL and set "Restrict MCP access to registry servers" to "Registry only" so that only servers in the registry run. GitHub documents the registry URL and allowlist as public preview.
- Claude Code: a
managed-mcp.jsonfile deployed to a system path (for example/etc/claude-code/managed-mcp.jsonon Linux) gives exclusive control of which servers load; an empty server map disables MCP. Alternatively, managedallowedMcpServersanddeniedMcpServerslists match servers byserverUrl,serverCommandorserverName, withallowManagedMcpServersOnly: truepreventing users from broadening the allowlist. The documentation warns thatserverNameis a user-assigned label and not a security control. - Other clients: check each supported agent client for an equivalent enterprise policy before approving it. A client that cannot be centrally restricted is itself a governance decision.
Identity provider consent controls
- Microsoft Entra: set user consent to "Allow user consent for apps from verified publishers, for selected permissions" and enable the admin consent workflow so users can request approval. Existing grants stay in place after the setting changes and must be reviewed separately.
- Google Workspace: in API controls, change unconfigured third-party apps from "Allow users to access any third-party apps" to a stricter option, and set approved agents to "Trusted", "Limited" or "Specific Google data" and others to "Blocked".
See the SaaS and OAuth App Governance Guide.
Network and CASB controls
- Sanction and block: in Microsoft Defender for Cloud Apps, marking an app unsanctioned does not block it on its own; with Defender for Endpoint Network Protection enabled, unsanctioned apps are blocked automatically and can be scoped to device groups with warn-and-educate. Other proxies use generated block scripts.
- Egress for servers you host: route self-hosted MCP servers and agent runtimes through an egress proxy, and block private ranges and
169.254.0.0/16from OAuth discovery fetches, as the MCP security best practices recommend against SSRF.
Requirements for anything you approve
- Remote servers require OAuth, validate token audience and never pass client tokens downstream.
- Local servers come from an internal registry or pinned versions, run sandboxed where the client supports it, and never take credentials from a committed config file.
- Scopes start minimal and step up only when an operation needs more.
- Each agent has a named owner and an entry in the AI register, with its tools and credentials listed.
- Tool definition changes trigger re-review.
Decision guidance: approve, contain or block
| Finding | Default decision | Condition to change it |
|---|---|---|
| Official vendor remote MCP server with OAuth, used for read access | Approve into registry | Contain if scopes are broader than the use case |
| Community local server wrapping a CLI with personal cloud credentials | Contain: remove config, rotate credentials | Approve a pinned, sandboxed version with a scoped role |
| Third-party agent app with full mail or file access | Revoke grant, request review | Approve with narrower scopes and a contract covering data use |
| Self-built script agent with a personal AI API key | Move key to secrets manager, register owner | Block if it handles regulated data without review |
| Known malicious or compromised package or server | Block everywhere, incident response | None |
- Small organisations: standardise on one or two agent clients that support central MCP control, use the vendor's managed allowlist, and close OAuth user consent. A spreadsheet register with owners is enough at first.
- Large organisations: run an internal MCP registry or gateway, feed endpoint and identity discovery into the AI register automatically, and tie approval to the existing software and third-party risk processes. See the MCP Gateway and MCP Server Governance Guide.
- Regulated environments: treat agents that can act on regulated data as Tier 3 by default and require an approved sandbox for local servers.
Implementing the programme
- Agree the approved route (weeks 1 to 2). Pick supported agent clients, publish a starter MCP registry of vetted servers, and add an "agent or MCP server" option to the AI request form.
- Discover in monitor mode (weeks 2 to 6). Run endpoint scripts that collect MCP configuration files, export OAuth grants from the identity provider, enable CASB discovery and scan repositories. Do not block yet.
- Triage and contact owners (weeks 4 to 8). Rate findings with the triage table, contact users, and approve, contain or retire each one. Rotate any credential found in a configuration file.
- Pilot enforcement (weeks 8 to 10). Apply registry-only or allowlist policies to one pilot ring, such as a platform team. Track blocked attempts and requests.
- Roll out in rings (weeks 10 to 16). Extend to all developers, then to all managed devices. Close OAuth user consent at the same time.
- Roll back safely. Keep the previous policy version; for registry policies, switching back to "Allow all" or removing the managed file restores access while you fix the registry. Record each rollback and its cause.
- Operate. Reconcile discovery with the register monthly and review approved servers when their tool definitions or versions change.
Detection and measurement
Monitor for these events:
- New MCP configuration files or changed server entries on endpoints and in repositories.
- Agent clients starting servers not in the registry, and blocked-by-policy events from managed clients.
- New OAuth consents to applications with AI-related names or high-impact scopes such as full mail or file access.
- Model provider API keys appearing in code, tickets or chat.
- Agent processes reading credential stores such as cloud CLI profiles or SSH keys, which maps to MITRE ATT&CK T1552.001 Credentials In Files.
Metrics that show the programme is working:
| Metric | Target direction |
|---|---|
| Share of discovered agents and MCP servers with a named owner and register entry | Towards 100% |
| Median days from discovery to decision | Down, under your policy target |
| Number of MCP server entries using static credentials in config files | Down to zero |
| Share of agent client installs under registry-only or managed allowlist policy | Up |
| Active OAuth grants to unapproved AI apps | Down |
| Requests through the approved route compared with new discoveries | Requests should exceed discoveries |
See the AI Usage Monitoring Guide.
Where identity fits
Most of the damage an unsanctioned agent can do comes from the credentials it inherits. A local MCP server started from a developer's shell can use their cloud session; a third-party agent holds a delegated OAuth token for as long as the grant lasts. Bringing an agent under governance therefore means giving it its own non-human identity, with scoped, short-lived credentials, a named owner and a revocation path. See the Identity Governance for AI Agents Guide and the AI Agent Authorisation Guide.
Framework mapping
| Control area | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | Threat references |
|---|---|---|---|
| Inventory of agents, servers and integrations | ID.AM-02, ID.AM-04 | CM-8, PM-5 | OWASP ASI10 Rogue Agents |
| Allowlisting and registry-only policies | PR.PS-05 | CM-7(5), CM-11 | D3FEND D3-EAL Executable Allowlisting; ATT&CK T1204 User Execution |
| Third-party servers and agent apps | GV.SC-04 | SA-9, SR-3 | ATT&CK T1195.002; ATLAS AML.T0010 AI Supply Chain Compromise |
| Delegated access and consent | PR.AA-05 | AC-6 | ATT&CK T1528 Steal Application Access Token; OWASP ASI03 |
| Tool use and untrusted input | DE.CM-09 | SI-4, AU-2 | ATLAS AML.T0053 AI Agent Tool Invocation, AML.T0051 LLM Prompt Injection; OWASP LLM06:2025 |
| Containment of rogue agents | RS.MI-01 | CM-10 | OWASP ASI02, ASI05 |
Common failure patterns
- Trusting repository configuration: agent clients that start servers defined in a cloned repository turn "open a folder" into code execution. In the Amazon Q MCP config vulnerability, Wiz reported that servers in
.amazonq/mcp.jsonstarted without a trust prompt and inherited the developer's AWS credentials; AWS's bulletin describes a workspace trust prompt, so accounts differ, but the fix shipped in later language server versions. - Approving a server once and never again: a package that behaved well at review can change. The postmark-mcp malicious MCP server was legitimate for fifteen versions before 1.0.16 added a hidden blind copy to every outgoing email.
- Ignoring the hosting layer: hosted MCP platforms concentrate credentials. In the Smithery.ai MCP hosting breach, researchers used a build path traversal to obtain a fly.io token controlling an organisation of 3,243 apps, mostly hosted MCP servers.
- Leaving grants in place after a tool is forgotten: in the Vercel Context.ai breach, a broad Google Workspace grant to a consumer AI app outlived its usefulness and became the attacker's way in after the AI vendor was compromised.
- Allowlisting by name: lists that match on server names users can choose give a false sense of control; match on URL or exact command instead.
- Blocking without an alternative: blanket blocks move agents to personal laptops and cloud accounts where you lose all visibility.
Practitioner checklist
- Choose supported agent clients and confirm each can enforce a central MCP allowlist or registry.
- Publish an approved MCP registry and an "agent or MCP server" request route with a target decision time.
- Collect MCP configuration files from managed endpoints and repositories, and reconcile them with the AI register monthly.
- Export and review OAuth grants to AI applications in Entra and Google Workspace; revoke unapproved ones.
- Restrict OAuth user consent to verified publishers and low-impact permissions, with an admin consent workflow.
- Rotate every credential found in an MCP or agent configuration file and move it to a secrets manager.
- Require OAuth with audience validation for approved remote servers, and pinned, sandboxed versions for local servers.
- Assign a named owner and a dedicated identity to every approved agent.
- Pilot registry-only enforcement in one ring before organisation-wide rollout, with a documented rollback.
- Report the six metrics above to the AI governance group every month.
Standards and references
- Model Context Protocol: Specification
- Model Context Protocol: Security Best Practices
- Model Context Protocol: Authorization
- NIST: AI RMF Playbook, Govern
- NIST: Cybersecurity Framework 2.0
- GitHub Docs: Configure MCP server access
- Anthropic: Control MCP server access for your organization
- Microsoft Learn: Configure how users consent to applications
Related NHI Mgmt Group resources: Shadow AI Discovery Guide · MCP Security Guide · Shadow AI Policy Template · AI Agent Tool and Plugin Security Guide · Top 10 Shadow AI Risks