Static MCP scanning checks manifests, tool descriptions, and hashes before deployment to catch poisoned instructions, shadowing, and schema changes. Runtime sandboxing controls what a tool can do after launch, including shell access, data movement, and jailbreak effects. Teams need both because static review finds risky code and metadata, while runtime controls contain behavior that only appears during execution.
Why Static MCP Scanning and Runtime Sandboxing Solve Different Problems
Static MCP scanning is about trust at release time: it looks for suspicious manifests, tool declarations, hashes, and schema drift before a server is allowed into use. Runtime sandboxing is about trust after launch: it constrains what the tool can actually do when it is invoked, including filesystem reach, shell execution, network movement, and access to sensitive data. The difference matters because MCP exposure is not only in code, but also in the metadata that steers how tools behave and what they can reach.
For teams operating MCP infrastructure, that distinction is practical rather than academic. A clean static review does not prevent a tool from abusing an overly broad runtime boundary, and a tight sandbox does not fix a poisoned description, a malicious dependency, or a configuration file that exposes secrets. Current guidance suggests treating MCP as both a supply-side trust problem and a live execution control problem. The State of MCP Server Security 2025 found that 53% of MCP servers expose credentials through hard-coded values in configuration files, which shows how often the risk starts before execution even begins.
In practice, many security teams only discover the weakness after a tool has already been granted broad execution room and the damage path is no longer theoretical.
How It Works in Practice
Static MCP scanning normally runs in the build or approval pipeline. It checks what is declared, not what is merely possible, so the goal is to catch tampering, shadowed tools, risky schema changes, and metadata that does not match the expected package or server identity. That makes it useful for reducing the chance that a bad tool is deployed in the first place. It is especially valuable when MCP servers are reused across teams, because the same manifest mistake can propagate widely.
Runtime sandboxing works at the opposite point in the lifecycle. Once the tool is launched, the sandbox limits the blast radius of a successful compromise or an overly permissive tool design. In MCP environments, that usually means narrowing file access, blocking or filtering shell execution, constraining network egress, limiting data transfer, and observing policy violations in real time. Sandboxing is not just a containment layer for malware; it is also a control against an agent or tool following instructions that were not anticipated during static review.
The two controls complement each other because they answer different questions:
- Static scanning asks whether the package, manifest, and declared tool surface look trustworthy before deployment.
- Runtime sandboxing asks whether the launched tool is behaving within acceptable boundaries right now.
- Static checks reduce supply-chain and configuration risk, while runtime controls limit the impact of prompt injection, tool abuse, and unexpected execution paths.
That split is important in protocol-driven systems because a benign-looking tool can still become dangerous once it receives live inputs, chained permissions, or access to connected systems. The OWASP Top 10 for Agentic Applications 2026 is useful background here because it frames how runtime behaviour, delegated actions, and trust boundaries can fail even when the initial artefact looked acceptable. For MCP-specific deployment context, the Ultimate Guide to NHIs — What are Non-Human Identities helps explain why machine-issued credentials and service identities need controls that survive beyond the static review stage.
These controls tend to break down when a tool is allowed to chain into other tools or inherit ambient access, because the sandbox can no longer meaningfully distinguish intended behaviour from delegated overreach.
Common Variations and Edge Cases
Tighter sandboxing often increases friction for developers and operators, so teams have to balance containment against workflow disruption and false blocks. That tradeoff becomes sharper when a legitimate tool needs temporary access to files, APIs, or shells during narrow tasks. Best practice is evolving here: there is no universal standard for how restrictive an MCP sandbox should be, but the control should be strict enough to prevent silent privilege creep and flexible enough to support documented use cases.
Static scanning also has limits. It can miss behaviour that only appears once a tool is fed hostile input, connected to a downstream system, or given an overbroad token. It can also produce a false sense of safety if teams treat manifest review as a substitute for execution governance. For that reason, static approval should be treated as a gate, not as proof of safe behaviour.
In edge cases, the deciding factor is not whether the tool is “good” or “bad,” but whether the deployment model allows it to fail safely. The most common mistake is to approve a tool because its package looks clean, then trust the runtime to absorb every other risk. That inversion leaves the organisation exposed to issues that only become visible after launch, including data leakage, unexpected command execution, and cross-system movement. The OWASP Agentic AI Top 10 is a useful companion reference when teams are deciding how much runtime autonomy is acceptable for tools that can act on behalf of users.
Practitioner guidance is simple: if a tool can touch production data or execute commands, static trust is never enough, and sandbox boundaries must be designed as if the tool will eventually be pushed outside its intended path.
Risk and Threat Considerations
The material risk is that static review and runtime containment are often confused, leaving one half of the control model effectively absent. A clean manifest does not prevent abuse after launch, and a sandbox does not protect against poisoned metadata, secret exposure, or supply-chain tampering before deployment. In MCP environments, that gap can create both confidentiality exposure and control-plane drift.
Failure mechanism: An attacker or malicious tool author can embed risky instructions, hidden tool behaviour, or weak credential handling in the deployed artefact, then rely on excessive runtime permissions, inherited tokens, or weak egress controls to convert that trust into execution and data access. If the sandbox is loose, the launched tool can pivot into shell commands, sensitive files, or connected systems.
Impact: The result can be secret exposure, unauthorized data movement, unapproved command execution, and lateral abuse of downstream systems. In coordinated deployments, the same weakness can scale across many MCP servers because a trusted pattern is copied into multiple environments.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS 4 — Secure Configuration of Enterprise Assets and Software | Static MCP scanning checks manifests and config for risky drift and exposed secrets. |
| CIS 6 — Access Control Management | Runtime sandboxing limits what a tool can do after launch and constrains access scope. | |
| CIS 8 — Audit Log Management | Runtime containment is stronger when tool actions and violations are logged for review. | |
| Recommendation — Scan MCP manifests and configuration before deployment to detect drift and insecure settings. Restrict tool permissions at runtime so launched MCP services cannot exceed approved access. Log MCP tool actions and policy violations to support detection and investigation. | ||
| MITRE ATT&CK | T1552 — Unsecured Credentials | Static review often needs to catch secrets or hard-coded credentials in MCP configs. |
| Recommendation — Hunt for exposed credentials in MCP artifacts and rotate any secrets found in configuration. | ||
| NIST CSF 2.0 | PR.DS — Data Security | The question centers on protecting data from exposed tools and runtime overreach. |
| Recommendation — Apply data-security controls that limit what MCP tools can read, move, or disclose. | ||
Practitioner Guidance
What to prioritise: Treat static scanning as an admission control and runtime sandboxing as a containment control. If you can only improve one first, close the runtime boundary around the highest-impact tools, because that is where a bad decision turns into real execution.
Decision rule: If the MCP server can reach sensitive data, invoke shells, or call external systems, require both pre-deployment review and a runtime policy that explicitly limits file, network, and command access. If either layer is missing, assume the overall control is incomplete.
What to verify: Confirm that the manifest actually matches deployed behaviour, that credentials are not embedded in configuration, and that the sandbox enforces the same limits under normal use and hostile input. A control is not trustworthy until it has been tested against the tool’s real permission path.
Practitioner takeaway: The right mental model is not “scan first or sandbox later,” but “prove trust before launch and constrain behaviour after launch,” because MCP risk lives in both the artefact and the execution path.
Related resources from NHI Mgmt Group
- What is the difference between static scanning and runtime protection for Java?
- What is the difference between static vulnerability scanning and runtime risk management?
- What is the difference between static scanning and runtime analysis in AppSec?
- What is the difference between static model scanning and runtime AI red teaming?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
