You lose the ability to baseline intended behaviour, detect drift, and prove who owns the server. Without function, schema, authentication, and data classification, an MCP deployment is just an endpoint list, and endpoint lists do not support reliable authorization governance or incident reconstruction.
Why This Matters for Security Teams
An MCP manifest is the contract that tells security, platform, and governance teams what a server is allowed to do, what data it touches, and who owns it. When that contract is missing or incomplete, the deployment becomes ambiguous by default: tools cannot be scoped, controls cannot be validated, and incident responders cannot reconstruct intent with confidence. That is why mcp security discussions increasingly overlap with OWASP Agentic AI Top 10 guidance on runtime behaviour and authorization drift.
This is not a theoretical documentation gap. NHIMG research on 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 means most teams are already operating with weak boundary definitions before the manifest problem is even addressed. In practice, many security teams discover the missing ownership and missing scope only after a sensitive tool has already been exposed to an agent or downstream workflow.
How It Works in Practice
A complete MCP manifest should give defenders enough context to answer four questions quickly: what functions exist, what schemas constrain those functions, how authentication is handled, and what data classification applies to each tool or resource. Without that metadata, policy engines cannot make meaningful decisions at request time, and platform teams cannot distinguish a legitimate tool call from an unsafe one. This is why manifest quality is now part of the broader control surface discussed in OWASP Agentic Applications Top 10 and in NIST-oriented control baselines such as NIST SP 800-53 Rev 5 Security and Privacy Controls.
Operationally, teams should treat the manifest as a governance input, not just developer documentation. A strong baseline usually includes:
- Tool inventory with explicit function names and allowed operations.
- Schema definitions that limit free-form input and make validation possible.
- Authentication requirements, token expectations, and ownership metadata.
- Data handling labels so sensitive fields can be blocked, minimized, or logged appropriately.
- Versioning so drift can be detected when the server changes but the manifest does not.
For incident response, the manifest helps separate design intent from misuse. If a tool was documented as read-only but later behaved like an update path, investigators can compare the published contract with observed activity and determine whether the issue was configuration drift, privilege expansion, or malicious abuse. That is especially important in AI-driven environments where tool chaining can hide the original source of access. NHIMG’s Analysis of Claude Code Security reinforces the same operational lesson: security posture depends on knowing what the system was designed to touch, not just what endpoints happen to be reachable.
These controls tend to break down when teams publish MCP servers quickly through CI/CD pipelines without a manifest review gate, because the server image changes faster than ownership, schema, and classification metadata can be validated.
Common Variations and Edge Cases
Tighter manifest governance often increases delivery overhead, requiring organisations to balance release speed against the value of reliable authorization and auditability. That tradeoff is real, especially in environments where tool inventories change daily and teams want to avoid paperwork for every small update.
Current guidance suggests that incomplete manifests are sometimes acceptable during early prototyping, but that should be treated as temporary and explicitly non-production. There is no universal standard for this yet, so teams should not assume that a vendor-specific manifest format is sufficient for enterprise governance. If the manifest lacks ownership, authentication details, or data classification, the safest interpretation is that the server has not been proven safe for broad access.
The biggest edge case appears when an MCP server is exposed to multiple agents, each with different task scopes. In that situation, a generic manifest can be misleading because it describes the server at rest, not the runtime context of each agent. Security teams should pair the manifest with policy checks, change control, and runtime logging so they can detect drift after deployment. The practical rule is simple: if the manifest cannot support authorization decisions or incident reconstruction, it is not complete enough to serve as a control artifact.
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 AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Missing manifests undermine identity, ownership, and control of non-human workloads. |
| OWASP Agentic AI Top 10 | A2 | Incomplete manifests enable unsafe tool use and runtime authorization drift in agents. |
| CSA MAESTRO | MAESTRO emphasizes agent governance, policy enforcement, and tool-access accountability. | |
| NIST AI RMF | AI RMF requires traceability, accountability, and risk monitoring for AI-enabled systems. | |
| NIST CSF 2.0 | PR.AC-4 | Access control depends on knowing which functions and data paths are in scope. |
Require every MCP server to declare owner, scope, and control metadata before production access.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 1, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
