Who should own exceptions for unscanned MCP packages and skill bundles?

The owning team should, with security review enforcing the policy. Exceptions need a named owner, a written rationale, and a time-bound revisit path so that allowlists do not become permanent blind spots. Without that discipline, exceptions quickly turn into unmanaged trust.

Why This Matters for Security Teams

Unscanned MCP packages and skill bundles are not just a hygiene issue. They are a supply-chain trust decision that can quietly expand what an AI agent or automation layer is allowed to execute. If exceptions are owned informally, the organisation loses the ability to prove why a package was trusted, who approved it, and when that trust expires. That is exactly how temporary operational shortcuts become permanent exposure.

This risk is especially visible in agentic environments, where package selection and tool invocation can happen dynamically. NHI Management Group has documented how agentic systems create new control gaps in OWASP Agentic Applications Top 10, and external guidance increasingly treats software provenance as a runtime governance problem rather than a one-time approval. The practical issue is not whether exceptions exist. It is whether they remain bounded, visible, and revocable. In practice, many security teams encounter unscanned MCP packages only after an exception has already been reused across multiple workflows and treated as normal operating permission.

How It Works in Practice

The owning team should own the exception request because it owns the operational need, the business impact, and the follow-up work required to remove the exception. Security should own the policy, review the risk, and enforce the approval standard, but it should not become the default business owner of an exception it does not use. That separation matters because the team that benefits from the package is best positioned to explain why scanning was bypassed and what compensating controls are in place.

A sound process usually includes four elements:

• A named business or platform owner for each unscanned MCP package or skill bundle.
• A written rationale that states why scanning could not be completed before use.
• Compensating controls such as restricted deployment scope, closer logging, or extra review for tool permissions.
• A time-bound revisit date so the exception is revalidated or removed.

This is consistent with the control intent found in NIST SP 800-53 Rev 5 Security and Privacy Controls, which expects accountable ownership, reviewable approvals, and ongoing control enforcement. For MCP-specific risk, the pattern described in the State of MCP Server Security 2025 shows why this discipline matters: 53% of mcp server expose credentials through hard-coded values in configuration files, and 24,008 unique secrets were exposed in MCP configuration files in 2025 alone. Those conditions make exception handling a high-risk control point, not a clerical step.

In practice, the approval record should be tied to the asset inventory or service catalog, not buried in chat threads or ticket comments. These controls tend to break down when the unscanned package is copied into multiple environments, because the original exception owner no longer has visibility into where trust was extended.

Common Variations and Edge Cases

Tighter exception control often increases delivery overhead, requiring organisations to balance release speed against assurance. That tradeoff becomes sharper when skill bundles are created by different teams, reused across projects, or pulled in through automation that changes faster than the review cycle.

There is no universal standard for this yet, but current guidance suggests two cases need extra caution. First, when an exception applies to a shared MCP package used by many teams, the platform owner should usually own the request while local service owners acknowledge downstream impact. Second, when the package supports an AI agent that can chain tools or act autonomously, the revisit path should be shorter because the blast radius is larger and harder to predict.

NHIMG research on LiteLLM PyPI package breach and Analysis of Claude Code Security reinforces a simple point: trust decisions around AI-adjacent tooling should be revocable, documented, and limited in scope. If an exception cannot name an owner, define compensating controls, and state an expiry, it is not really an exception process. It is an unmanaged allowance.

Related resources from NHI Mgmt Group

• How can organizations manage the risk of credential leaks in MCP frameworks?
• What challenges do unmanaged API keys pose within MCP?
• Who should own remediation when CTEM findings touch identities and workloads?
• What frameworks help with MCP server governance and least privilege?