Securing MCP at
Defense Enterprise Scale

Model Context Protocol makes it straightforward for AI agents to call tools and retrieve context from systems. That convenience is also the threat surface. Once an agent can do things — create tickets, pull classified repositories, rotate keys, trigger deployment pipelines, query sensor data — the tool layer becomes the most consequential control plane in your environment. Treat it accordingly.

This guide distills operational security controls for MCP deployments at defense enterprise scale. It is aligned with NIST SP 800-53 Rev 5, OWASP Top 10 for LLM Applications, and DoD STIG requirements, and shows how Fulcrum operationalizes each control through its native architecture — not as an add-on layer, but as the platform's default behavior at every impact level.

1 Establish an MCP Server Inventory and Trust Boundary

Before any security control can be enforced, you need a complete answer to three questions: what MCP servers exist in your environment, what tools they expose, and which identities are authorized to call them. In a defense context, this is not optional hygiene — it is a prerequisite for any ATO conversation.

An unregistered MCP server in a classified environment is a shadow IT problem with an AI-shaped threat surface. It can be called by any agent that discovers it, invoked with any parameters that pass schema validation, and — without centralized logging — leave no trace in your audit record.

• Maintain an approved MCP server registry. For each server: owner, mission purpose, environment (dev/test/prod/IL tier), full tool list, risk tier, and authorization status. This registry is your ATO artifact for the MCP layer.
• Enforce tool allowlists per workspace. No agent should have access to the full tool surface of every server. Each workspace gets a scoped allowlist that matches its mission and classification level.
• Pin server versions and dependency digests. Floating version references are a supply chain risk. Every registered server should be pinned to a validated digest, with a documented update process that includes re-validation.
• Apply provenance checks to all third-party MCP servers. In a defense deployment, any server not built and maintained by your program office or a vetted partner requires explicit provenance documentation before it enters the registry.

How Fulcrum operationalizes this: The Fulcrum workspace is the source of truth for your MCP server registry. Server onboarding flows through a structured intake task — owner, risk tier, tool manifest, approval chain — and the workspace thread captures every decision, exception, and configuration change. When an auditor asks what was authorized when, the answer lives in the workspace, not in a spreadsheet someone forgot to update.

2 Treat Every Tool Call as a Privileged Operation

MCP doesn't eliminate the requirement for classical access control. It intensifies it. A tool call is not a chat message — it is an authenticated action against a real system. At IL4 and IL5, the consequences of an improperly scoped tool call can include data exfiltration, unauthorized modification of mission-critical records, or accidental exposure of controlled unclassified information to an agent operating at the wrong classification level.

The foundational principle is least privilege: every agent identity, in every workspace, for every tool interaction, gets the minimum authorization required to complete its assigned mission function — nothing more.

• Separate identities for humans and agents. Agent service accounts are distinct from human user credentials. A Codex agent running a build pipeline should never be operating on a human engineer's credential context, with its broader entitlements and audit ambiguity.
• Short-lived, scoped credentials only. Fulcrum MCP sessions use OAuth 2.1 with short-lived tokens scoped to the specific workspace and tool set. No persistent secrets. Token rotation is enforced at the protocol level — not as a configuration option, but as the default behavior.
• Read-only by default; explicit write grants. Every tool that modifies state — creates records, updates configurations, deletes data, triggers pipelines — requires an explicit authorization grant. The default posture is read access. Write access is audited and attributed to a specific agent identity for every invocation.
• Step-up controls for sensitive operations. High-sensitivity tool calls — anything touching credentials, production configurations, or classified data — require an additional authorization event before execution. In Fulcrum, this is the Human-in-the-Loop gate: the agent cannot proceed until a credentialed human reviewer explicitly approves the action.

3 Defend Against Prompt Injection and Unsafe Output Handling

OWASP's Top 10 for LLM Applications identifies two failure modes that appear consistently in deployed agent systems. Both are architectural, not incidental — they require deliberate controls, not awareness alone.

Prompt Injection occurs when untrusted external content — a ticket description, a document pulled from a repository, a message from an external system — contains instructions that cause the agent to take actions outside its authorized mission scope. At the most dangerous end of this spectrum, a carefully crafted input in a classified document repository could instruct an agent to exfiltrate data, modify access controls, or call tools it was never intended to invoke.

Insecure Output Handling occurs when an agent's output is treated as trusted and executed without validation — when generated code is deployed, when a generated IAM policy is applied, when a generated configuration file is pushed to production. The agent's confidence is not a validation mechanism. The output must be checked before it executes.

• Treat all external content as untrusted input. Issues, emails, documents, web content, tickets — regardless of source or classification marking — are untrusted text until explicitly validated. Agents should never concatenate raw external content into tool command strings.
• Enforce strict tool schemas with argument validation. Every tool call must have schema-validated arguments: types checked, ranges bounded, allowed values enumerated. An agent should not be able to call a tool with a parameter it wasn't authorized to provide.
• Require output validation before downstream execution. Generated code, configurations, queries, and policies must pass a validation step before execution. In Fulcrum, this is a structured review task — the output is posted to the workspace, a validation agent or human reviewer confirms it, and execution proceeds only after sign-off.

How Fulcrum operationalizes this: Fulcrum enforces a Plan-Then-Act default for all agent workflows. Before any tool-calling sequence begins, the agent posts a structured execution plan to the workspace — what tools it intends to call, with what parameters, toward what objective. This plan is visible to all workspace participants and creates a review checkpoint before any action touches a real system. The workspace thread captures the plan, the approval, and the execution record in a single continuous audit chain.

4 Human-in-the-Loop Gates for High-Impact Actions

Not every tool call requires manual review. Routine read operations, status queries, and low-risk information retrieval can run with automated oversight. But a specific category of tool calls should never execute without explicit human approval — regardless of how confident the agent is, how well-formed the request looks, or how routine the action appears in isolation.

In a defense enterprise environment, that category includes any tool call that modifies production systems, touches credentials or secrets, deletes or overwrites data, triggers irreversible actions, or operates at a higher classification level than the agent's normal workspace scope.

• Approval gates for destructive and high-risk tools. These gates are not configurable pop-ups — they are hard stops. The tool cannot be invoked until a credentialed approver explicitly signs off on the specific action with the specific parameters the agent intends to use.
• Previews and dry runs before execution. Where possible, agents should generate a preview of the action — a diff, a dry-run output, a "what will change" summary — before requesting approval. This is especially important for configuration changes and data operations.
• Two-person review for production changes. For operations that modify production systems or classified data, require two independent approvers from distinct organizational roles. This mirrors the two-person integrity rule that defense programs already apply to physical systems.

How Fulcrum operationalizes this: Human-in-the-Loop gates are a native primitive in the Fulcrum workspace — not a bolt-on approval workflow, but a first-class platform operation. The agent posts the pending action, the parameters, and the preview to the workspace as a structured approval task. The task is assigned to a credentialed approver. The agent cannot proceed until the task is explicitly resolved. The resolution — approval or rejection, with the approver's identity and timestamp — is captured immutably in the audit trail alongside the original tool call record.

5 Centralize MCP Traffic Through a Gateway

Direct client-to-server MCP connections scale poorly and create enforcement gaps. As the number of agents and servers in your environment grows, the number of unmonitored connection surfaces grows with it. A gateway architecture gives you a single, auditable choke point for every MCP interaction in the environment.

For IL4 and IL5 deployments, a gateway is not optional — it is the mechanism by which you can credibly assert that all tool calls are authenticated, all parameters are logged, and all traffic is rate-limited. Without a gateway, your ATO assertion about MCP security is theoretical.

• Mutual TLS or equivalent strong client authentication. Every agent connecting to the MCP gateway presents a validated client certificate. Anonymous or weakly authenticated connections are rejected at the gateway before they reach any server.
• Centralized authorization decisions. The gateway is the enforcement point for workspace-level tool allowlists. An agent carrying a valid token for workspace A cannot call tools from workspace B's allowlist by connecting directly to the server.
• Structured audit logs with full attribution. Every tool call logged at the gateway should capture: agent identity, workspace, tool name, parameters (appropriately redacted for classified content), timestamp, response status, and latency. This is your IL5 audit record.
• Rate limits and concurrency controls. Runaway agents — stuck in loops, processing unexpectedly large inputs, or responding to injected instructions — can consume disproportionate resources and mask their activity in volume. Rate limits and concurrency caps at the gateway provide a first line of defense against this pattern.

6 Contain Blast Radius at Runtime

Even with a complete access control architecture, servers can be compromised, agents can behave unexpectedly, and edge cases in tool schema validation can create exploitation windows. Defense-in-depth requires treating your MCP server runtime as potentially hostile and designing containment so that a compromise of one server cannot cascade into the broader environment.

• Isolated container execution. MCP servers run in non-root containers with no privilege escalation path. Container images are scanned against known vulnerability databases before deployment and on a continuous basis in production.
• Network egress restriction. MCP servers should only be able to reach the endpoints they explicitly require. An allowlist-based egress policy means that even a compromised server cannot exfiltrate data to an arbitrary external destination.
• Resource quotas and concurrency limits. CPU, memory, request timeout, and concurrent connection limits are set per server. A server experiencing unexpected load — whether from a runaway agent loop or an active attack — trips its quota before it can destabilize adjacent systems.
• Hard environment separation. Dev, test, and production MCP runtimes are not connected by any network path or shared credential. An experiment in the IL2 dev environment cannot accidentally call a production server or access production data.

7 Treat Security as a Continuous Program, Not a One-Time Hardening Pass

NIST's AI Risk Management Framework (AI RMF 1.0) describes a four-function cycle: Govern, Map, Measure, Manage. The intent is explicit: AI security is not a checklist you complete before deployment. It is a continuous risk management program that runs in parallel with operations.

For MCP deployments at defense enterprise scale, this means the security work you do before go-live is the foundation — not the conclusion. The threat model changes as agents gain new capabilities, as tools are added to the registry, as classification levels change, and as adversaries develop new techniques for exploiting LLM agent architectures.

• Govern: Define ownership, risk acceptance thresholds, and escalation paths for agent/tool workflows. Every workspace should have a named security owner and a documented risk acceptance statement.
• Map: Document where each agent can pull context from and where it can act. This mapping is the authoritative source for your tool allowlists and the basis for your blast radius analysis.
• Measure: Track security incidents, near-misses, anomalous tool call patterns, and control coverage metrics. The Fulcrum audit trail provides the raw data; program security reviews provide the analysis cadence.
• Manage: Continuously improve controls as the threat model evolves. Rotate credentials on schedule. Patch and re-validate servers when vulnerabilities are disclosed. Update gateway policies when new tool categories are onboarded.

How Fulcrum operationalizes this: The Fulcrum workspace is the operating system for continuous improvement. Security incidents become structured tasks. Postmortem findings become new control requirements. Control requirements become workspace templates that propagate to every new deployment. The security program compounds — each incident makes the next deployment harder to attack.

★ Implementation Sequence for Fulcrum Deployments

If you are standing up a new Fulcrum deployment and want to implement these controls in priority order, this is the sequence. Each step builds on the last and corresponds to a specific IL readiness milestone.

§ References