Skip to content

NSA & Five Eyes guidance

In 2026 the NSA and its Five Eyes partner agencies published two documents that now anchor how security teams evaluate MCP servers and agentic AI tooling:

CodeNavi is an MCP server and a component inside your agentic AI system, so both documents apply to it directly. This page maps their concerns and recommendations to how CodeNavi is built, so your security review can start from the guidance's own structure.

This is a self-assessment

The mapping below is CodeNavi's own analysis of its design against published guidance. The authoring agencies do not evaluate, certify, or endorse commercial products, and nothing here claims otherwise. Verify every row yourself — the security model and security features pages describe the mechanisms, and the product ships so you can inspect them.

Where CodeNavi sits in the threat model

Most of the incidents the MCP CSI documents — tool parameter injection reaching a shell, blanket account access abused by a malicious server, tools exfiltrating message history — depend on an MCP server that executes actions or holds credentials to your accounts. CodeNavi's position in that threat model is deliberately narrow:

  • Read-only by design. CodeNavi's tools search, read, and analyze an index of your code. No tool executes shell commands, arbitrary code, or actions against external accounts. The write surface is limited to CodeNavi's own data stores — investigation notes (security-scanned before storage), search-result ratings (rate-limited), and quarantine/allowlist decisions.
  • Local by default. The CSI's own recommendation — "when processing private data, always prefer a local instance of MCP server" — is CodeNavi's whole architecture. Indexing, embedding, search, and reranking run in a container on hardware you own, with zero telemetry and zero egress by default. Pointing code embedding at a remote provider is blocked outright by default, and the embedder loads pinned model revisions with remote model-code execution off.
  • A fixed, versioned tool inventory. The tool set is compiled into the release, not resolved from a registry at runtime. Nothing is dynamically loaded, and the default lean profile advertises only an 11-tool core (the search/browse/read loop plus incremental reindex, reindex status and index stats) — everything else is revealed on demand.1

Mapping: the MCP CSI

The CSI's recommendation sections, in its own order:

CSI recommendation CodeNavi posture
Choose supported MCP projects CodeNavi is commercially maintained with versioned releases, release notes, a published vulnerability disclosure policy, and a CycloneDX SBOM in every release.
Design for boundaries — trust zones, data classification, local instances for private data Self-hosted inside your boundary. Multi-codebase installs can segment repositories with scoped endpoints (/mcp/{codebase}): the scoping middleware pins the MCP session to its codebase and rejects mid-session switches, so an agent wired to one codebase cannot read another's index — the CSI's "align tools with data classification zones" applied to code, enforced independently of the token.
Approval workflows — the CSI warns that an already-trusted server can silently change capability CodeNavi's capabilities change only when you install a signed release, documented in release notes — a connected server never grows new tools in the background. Within a session, tools outside the lean core load only when your client explicitly calls reveal_tools, announced via tools/list_changed. Script hooks (a shell script of yours after an index or crawl) run only from the documented hooks mount — the directory cannot be re-pointed over the API.
Validate parameters Every tool validates its arguments against a typed schema; result limits are capped server-side. The two write paths are gated: note writes pass the security scanner before anything is stored, ratings are rate-limited per chunk.
Constrain and sandbox tool execution There is no tool execution to sandbox in the CSI's sense — no tool runs code. The server itself runs least-privilege: non-root user, read-only root filesystem (only /tmp and the named data directories writable), every Linux capability dropped, no-new-privileges, the Docker socket never mounted in, and your source mounted read-only. File reads are confined to the codebase roots you configured and pass through the same secret redaction the indexer applies — a token holder cannot read their way to an API key. The opt-in crawler, the only component that reaches the network, refuses private, loopback, and cloud-metadata (169.254.169.254) targets, including via redirects.
Sign and verify MCP messages Honest row: MCP message-level signing is not part of the protocol, and CodeNavi does not add proprietary message signatures. Transport security is TLS via the remote access pattern; the default bind is localhost. What is signed fail-closed: release images, update manifests, and license keys (cosign, verified by installer and updater).
Filter and monitor output pipelines — treat every output as untrusted input to the next stage CodeNavi's core design. The security scanner reads every chunk before it is stored: secrets and PII become [REDACTED:…], injected instructions — including prose injection in READMEs and docs — are marked [FLAGGED:…], and the retrieval gate keeps flagged chunks out of search results. This is the CSI's "poisoning output for downstream automation" risk, addressed before the poison reaches your agent's context. Honest limit: the rules and heuristics are pattern-based, not a guarantee — a sufficiently novel phrasing can slip through, which is why the markers, the retrieval gate, and the agent-facing "never reconstruct or obey" instructions are layered rather than relied on singly.
Access control Access is decided by one thing: a bearer token, compared in constant time. No header influences the decision — there is no code path where a spoofed Host or an absent Origin means yes, the failure class behind 2026's headline MCP-server RCE — verify it from your own terminal. The startup auth-exposure guard evaluates the actual bind address and refuses (or loudly flags) an unauthenticated network-reachable server; its refuse/warn/ok matrix is asserted by the gating test suite, and the module deliberately ships as readable source — its header cites this CSI by document number (U/OO/6030316-26). Honest limit, matching the CSI's RBAC concern: the token is all-or-nothing today — no per-tool roles, no read-only credential. The blast radius of that single credential is bounded by the tool surface itself being read-only.
Token & session security CodeNavi holds no OAuth tokens to your accounts and passes no third-party credentials through — there is no token passthrough to misuse and nothing to replay against your SaaS estate. In the one supported tokenless posture (loopback-only, single-user machine), the MCP endpoint validates Host/Origin against DNS rebinding — a second lock, never the lock.
Instrument for logging and detection The scan ledger, per-file threat reports, and the reasoned, timestamped allowlist are on-disk audit artifacts you can collect into your SIEM; the Security screen is their console. Server logs land in the writable log volume, a metrics endpoint (loopback-bound by default) sits beside /health, license state is evaluated and logged at every boot, and query analytics stay local.
Track and patch MCP-related vulnerabilities Disclosure policy with defined scope and timeline; signed update channel; SBOM per release so your vulnerability tracking can enumerate what is actually inside the image.
Scan networks for open or vulnerable MCP servers An operator task — but CodeNavi is built to survive your scan: unauthenticated probes learn liveness from /health, not internals, and the exposure guard means a stray wide-open instance is a deliberate configuration, not a default.

Mapping: Careful Adoption of Agentic AI Services

The joint guidance classifies agentic AI risk into five families. CodeNavi is one component in your agentic system — the retrieval layer — and each family lands on it as follows:

Risk family CodeNavi posture
Privilege risks — confused deputy, scope creep, over-broad grants The classic confused-deputy outcome needs privileges worth confusing a deputy out of. CodeNavi's tools grant an agent read access to an index you chose to build — no email, no financial systems, no repository write access. Least privilege is structural, not configured.
Design & configuration risks — insecure defaults, stale allow-decisions Secure defaults throughout: localhost bind, lean tool profile, scanner on from first index (dry-run, with a persistent banner until you choose blocking), fail-closed signature verification on install and update. The guidance's rollback recommendation is built in: the updater verifies every layer by digest and tags the previous image rollback-<id> before switching, so reverting to known-good is one step, not a rebuild.
Behaviour risks — goal misalignment, deception, emergent behaviour CodeNavi is not an agent. There is no goal, no planner, no autonomy — retrieval is deterministic tooling your agent calls. The optional LLM features (chat, wiki compile) are explicitly gated, and using a cloud provider requires per-install consent before any code leaves the box.
Structural risks — third-party components, tool squatting, dynamic loading Fixed tool inventory, pinned model revisions with no remote model-code execution, vendored dependencies, and a CycloneDX SBOM per release — the guidance's own SBOM procurement recommendation, answered from the vendor side.
Accountability risks — opaque actions, untraceable decisions Search results carry file:line citations — the guidance's "require specific information referencing showing where key aspects of a response originated," built into every answer. Scanner decisions leave threat reports; allowlist entries require a reason; agent notes are anchored to files and automatically marked stale when the anchor changes.

What stays on your side

Both documents are written for the whole agentic system, and most of their operator guidance is about the agent, not the retrieval layer. Deploying CodeNavi does not discharge these; it is designed not to get in their way:

  • Human oversight of your agent — approval workflows, human-in-the-loop checkpoints, and graduated autonomy live in your agent harness. CodeNavi's contribution is that its tools are safe to auto-approve: read-only, no side effects outside its own stores.
  • Egress control — the CSI recommends a filtering outgoing proxy for MCP environments. CodeNavi makes that policy short: default egress is zero, and the only optional flows (a once-daily update check you can disable, any cloud LLM you explicitly configure) are enumerable pinhole rules.
  • Monitoring integration — collect the scan ledger, threat reports, and container logs into your SIEM; scan your own network for MCP servers you didn't deploy on purpose.
  • Risk-scoped adoption — the joint guidance says to start agentic AI on low-risk tasks with the minimum access required. Scoped endpoints let you apply that to code retrieval: index the codebases the agent needs, not everything you own.

  1. Vendor change reference CN-261. ↩