A real pilot has a curated catalog, audit logs, role-based access control, and a named platform owner who can approve or revoke access. If users still rely on ad hoc local setups for the same tasks, the pilot is not replacing shadow usage, only duplicating it.
Why This Matters for Security Teams
An MCP pilot is only governed when the organisation can prove what was connected, who approved it, what it could access, and whether that access was actually used as intended. Without that evidence, a pilot is just a new channel for the same shadow workflows it was supposed to replace. The risk is not limited to policy drift. It includes hidden credentials, overbroad tool permissions, and unreviewed local setups that continue to move data outside the approved control plane.
That matters because MCP changes the boundary of access. A curated catalog is useful, but governance starts when access is deliberately scoped and auditable, not when the server is simply reachable. NHIMG’s The State of MCP Server Security 2025 found that only 18% of mcp server deployments implement any form of access scoping for tool permissions, which is a strong signal that pilots often begin before control discipline exists. Current guidance from NIST Cybersecurity Framework 2.0 and OWASP Agentic AI Top 10 supports the same basic test: can the organisation detect, constrain, and review access in practice?
In practice, many security teams discover the pilot is not governed only after a leaked secret, an audit request, or a production incident exposes the local setup that never entered the approval process.
How It Works in Practice
Governed MCP pilots behave like controlled access programs, not informal developer experiments. The first requirement is a curated catalog of approved servers and tools, with a named owner for each one. That owner should approve changes, review usage, and revoke access when a pilot ends or a risk changes. The second requirement is identity and access discipline: role-based access control for humans who configure the pilot, plus tool-level scoping so the MCP server only exposes the minimum functions needed for the use case. The third is evidence.
Evidence means audit logs that answer four questions: who connected, what tool was invoked, what data or secret was touched, and whether the action was expected. That logging should be paired with credential hygiene. NHIMG’s Top 10 NHI Issues and Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs both point to the same operational truth: if secrets are long-lived, broadly shared, or hard-coded into configuration, the pilot cannot be said to be governed. This is consistent with NIST SP 800-53 Rev. 5 Security and Privacy Controls, which treats access control, accountability, and configuration management as inseparable controls.
- Keep an authoritative inventory of MCP servers, owners, and allowed tools.
- Require approved identity, scoped permissions, and revocable credentials for every connection.
- Review logs for shadow usage, unexpected tool chaining, and access outside the pilot’s purpose.
- Block local copies of the same workflow when they bypass the governed path.
These controls tend to break down when teams allow developers to stand up parallel local MCP configurations for convenience, because the pilot then becomes one more approved path rather than the only controlled path.
Common Variations and Edge Cases
Tighter governance often increases setup friction, requiring organisations to balance speed for experimentation against the overhead of review, approvals, and logging. That tradeoff is real, and there is no universal standard for it yet. For low-risk internal pilots, some teams accept broader access temporarily, but current guidance suggests that any exception must be time-boxed, documented, and visible to the platform owner.
The most common edge case is a pilot that looks governed at the platform level but still fails in practice because users keep private notebooks, local API keys, or untracked connectors on their desktops. Another common failure mode is fragmented oversight: the security team approves the pilot, but the platform team owns the logs, the app team owns the prompt flow, and nobody can revoke access quickly. That is exactly where pilot governance becomes performative. For emerging MCP and agentic workflows, the combination of Astrix Security research and the OWASP Agentic AI Top 10 reinforces a simple rule: if access cannot be scoped, logged, and revoked, the pilot is not governed, only branded as such.
Organisations should treat that as a decision gate, not a maturity milestone. If the same work still happens outside the pilot, the control environment has not displaced shadow usage and the governance claim does not hold.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers scoped access and credential discipline for non-human identities. |
| OWASP Agentic AI Top 10 | Addresses governed tool access and unsafe autonomous interaction patterns. | |
| CSA MAESTRO | Covers governance patterns for managed agent and tool ecosystems. | |
| NIST CSF 2.0 | PR.AC-4 | Access control and accountability are central to a governed pilot. |
| NIST AI RMF | Govern function supports accountability for AI-enabled access decisions. |
Use agentic controls to restrict tool use, log actions, and block uncontrolled workflows.
