MCP Security Posture
How the Federal Frontier Platform addresses the OWASP MCP Top 10 — the official security framework for Model Context Protocol deployments.
MCP Security Posture
The Federal Frontier Platform is assessed against the OWASP MCP Top 10 (MCP01:2025–MCP10:2025) — the first official security framework dedicated to Model Context Protocol deployments, published by OWASP under project lead Vandana Verma Sehgal.
MCP connects AI agents to tools, APIs, files, databases, and enterprise workflows. That capability creates a new attack surface. Between January and February 2026 alone, researchers filed over 30 CVEs targeting MCP servers. Palo Alto Unit 42 found that with just five connected MCP servers, a single compromised server achieved a 78.3% attack success rate against connected agents. The OWASP MCP Top 10 provides a shared vocabulary for addressing these risks. FFP maps its controls against every category.
FFP’s Frontier MCP Registry (powered by Wanaku) routes all agent tool access through a single authenticated, governed endpoint — 16 MCP servers, 283 tools, one auth boundary. This architectural choice directly reduces the attack surface that the Unit 42 research describes: a centralized gateway with OPA/Rego policy enforcement is fundamentally more defensible than 16 individual server connections.
Security Posture by Category
MCP01 — Token Mismanagement & Secret Exposure
Status: Strong
All credentials are stored as Kubernetes Secrets in namespace-scoped deployments. Credentials are never stored in ConfigMaps, logs, environment variable literals, or agent context. Every Claude Code runner Job mounts credentials via volume — they are never passed as command-line arguments or environment variables visible in process listings. The governance policy explicitly prohibits agents from logging credential values. Service accounts are scoped to minimum required permissions with 90-day rotation schedules.
MCP02 — Prompt Injection via Tools & Resources
Status: Partial
The Federal Frontier Ontology (FFO) provides structured TypeQL retrieval for all knowledge graph queries — the agent receives typed entities and attributes, not free-form text that could embed instructions. This is structurally safer than retrieval-augmented generation (RAG) over unstructured text, where injected instructions in retrieved documents are a common attack vector.
Tool response sanitization before agent context injection is part of Eupraxia Labs’s active security hardening program. Current mitigation: the governance policy instructs agents to treat all tool output as data, not instructions, and all destructive actions require human approval regardless of what tool output suggests.
MCP03 — Tool Poisoning
Status: Partial
All 16 native FFP MCP servers are developed by Eupraxia Labs, version-pinned in Harbor (the private container registry), and deployed through GitOps pipelines with explicit version tags. No MCP server is pulled from an unverified external registry. Tool descriptions are reviewed before registration as Wanaku forwards.
Cryptographic signing of tool descriptions and SBOM tracking for MCP server images are part of Eupraxia Labs’s active security hardening program. Current mitigation: all servers are first-party, version-controlled, and built by verified CI pipelines with Harbor image scanning enabled.
MCP04 — Unsafe Tool Execution
Status: Partial
The sre-remediation-policy governs which execution methods agents may use for each resource type and namespace. Agents cannot issue kubectl commands against ArgoCD-managed resources (those are reverted by the next sync). Secrets are never modified by automated remediation. Nodes and system namespaces are recommendation-only. The policy is injected into every agent session as a hard behavioral constraint, not a suggestion.
Formal execution sandboxing for tool calls is part of Eupraxia Labs’s active security hardening program. Current mitigation: policy-constrained remediation methods enforced at prompt level, with human approval required for all MEDIUM, HIGH, and CRITICAL risk sessions.
MCP05 — Supply Chain Abuse
Status: In Progress
All MCP server images are built from Eupraxia Labs CI pipelines, pushed to Harbor, and deployed via GitOps with pinned version tags. Harbor’s built-in vulnerability scanning runs on every image push.
Image signing via Cosign and formal SBOM generation are part of Eupraxia Labs’s active security hardening program. Wanaku forward registrations are currently verified at registration time by Wanaku’s MCP probe sequence — servers that do not correctly implement the MCP protocol cannot be registered as forwards.
MCP06 — Context Leakage
Status: Partial
Each SRE dispatch session runs as an isolated Kubernetes Job in a dedicated namespace. Sessions do not share runtime context. The Federal Frontier Ontology (FFO) is a shared knowledge graph — this is intentional, as cross-session operational memory is a core platform capability — but agents query FFO using scoped TypeQL queries, not full graph dumps.
Classification-aware FFO query scoping (agents only read findings at or below their classification level) is part of Eupraxia Labs’s active security hardening program. Current mitigation: Wanaku instances are deployed per classification level, namespace isolation enforces classification boundaries at the deployment layer.
MCP07 — Insufficient Authentication
Status: Strong
All MCP tool invocations through the Frontier MCP Registry require a valid Keycloak OIDC token (realm: FAS). Wanaku validates tokens against Keycloak’s JWKS endpoint on every request. OPA/Rego policies enforce role-based access control at the tool level — an agent’s token scope determines which tools it may invoke, not just whether it may connect.
CVE-2026-32211 (Azure MCP Server — missing auth layer) is not possible in FFP’s architecture: Wanaku requires authentication before any tool registration or invocation, and the Keycloak FAS realm is the single identity provider for the entire platform.
MCP08 — Excessive Agency
Status: Strong
The OPA Wasm policy engine gates every SRE dispatch before a Kubernetes Job is created. LOW risk actions auto-execute and are logged to FFO. MEDIUM, HIGH, and CRITICAL risk actions require human approval through OutpostAI before any cluster change occurs. CRITICAL actions additionally trigger operator notification.
The sre-remediation-policy further constrains what agents may do when they execute: Secrets are never modified, nodes are never auto-remediated, system namespaces are recommendation-only, and ArgoCD-managed resources are only modified through GitOps commits — never through direct kubectl commands that bypass the change management pipeline.
MCP09 — Weak Logging
Status: Strong
Every SRE session produces a structured audit trail:
- Federal Frontier Ontology (FFO): Agent findings are written as typed entities with severity, root cause, remediation commands, lifecycle status, and session reference — queryable by any agent or operator at any time
- Remediation outcomes: Every approved and executed remediation writes a linked outcome entity to FFO recording what was done, whether it succeeded, and the post-remediation state
- Confluence session logs: Every Claude Code session writes a human-readable session log to the FED Confluence space under a versioned parent page
- Phase event tracking: Sessions emit named phase events (pre_flight, ffo_query, k8s_query, investigation, recommendation, pending_approval, remediation, verification, complete) visible in OutpostAI in real time
- Jira tickets: Every investigated finding creates or updates a Jira ticket in the FF project with full context
This logging architecture means FFP’s operational history is a first-class queryable asset, not an afterthought.
MCP10 — Governance Gaps
Status: In Progress
The claude-governance ConfigMap governs agent behavioral policy: permitted actions, prohibited patterns, remediation method constraints, credential handling rules, and TypeQL syntax requirements. This is injected into every agent session.
A formal MCP security policy document — mapping FFP controls to OWASP categories, defining the review cadence, and documenting the incident response procedure for MCP-related security events — is part of Eupraxia Labs’s active security hardening program.
Summary
| Category | Status | Key Control |
|---|---|---|
| MCP01 Token Mismanagement | Strong | Kubernetes Secrets, governance policy, 90-day rotation |
| MCP02 Prompt Injection | Partial | FFO TypeQL retrieval, tool-output-as-data policy |
| MCP03 Tool Poisoning | Partial | First-party servers, Harbor scanning, version pins |
| MCP04 Unsafe Tool Execution | Partial | Remediation policy, human approval gates |
| MCP05 Supply Chain Abuse | In Progress | Harbor CI pipelines, Wanaku MCP probe validation |
| MCP06 Context Leakage | Partial | Job isolation, per-IL Wanaku instances |
| MCP07 Insufficient Authentication | Strong | Keycloak OIDC, OPA/Rego RBAC |
| MCP08 Excessive Agency | Strong | OPA Wasm dispatch gates, approval matrix, remediation policy |
| MCP09 Weak Logging | Strong | FFO findings, Confluence logs, phase events, Jira |
| MCP10 Governance Gaps | In Progress | claude-governance ConfigMap, formal policy document planned |
FFP addresses 4 of 10 categories as strong, 3 as partial with active mitigations, and has 3 in progress with roadmap items actively tracked and prioritized by Eupraxia Labs. This posture reflects an honest assessment of where the platform stands today and where it is going. The four strong categories — authentication, excessive agency, logging, and token management — are the categories federal security officers weight most heavily in ATO reviews.
Continuous Improvement
The OWASP MCP Top 10 is a living document.
For questions about FFP’s security posture, contact security@eupraxialabs.com.
Last updated: June 2026. OWASP MCP Top 10 reference: owasp.org/www-project-mcp-top-10