We Compared Three AI-Agent Security Launches. They Do Not Protect the Same Path.

Our source set is deliberately small: the Nightfall MCP Gateway announcement dated September 9, the Traefik Sovereign Trust Plane announcement dated September 15, and the Lumos MCP Governance announcement dated September 22. We selected them because each announced a control around agent access or tool use that month and published enough first-party detail to inspect its enforcement point. We did not select them because they are the three largest products, the best products, or a representative sample of the entire market.

For each launch, we checked the announcement against at least one more detailed first-party page available on September 28: Nightfall's gateway documentation, Traefik's product overview, and Lumos's technical explanation and product page. We recorded the claimed interception point, supported traffic, identity and credential model, policy action, audit evidence, bypass or coverage boundary, and stated availability. A published claim counted as a claim; we did not infer a capability from a diagram or treat a customer logo as a test result.

The independent reference points are narrower than product validation. NIST's February 2026 agent-identity concept paper identifies agent identification, authorization, audit, and non-repudiation as questions for a potential project. The OWASP Agent Control Standard, published September 1, describes inspectable agent activity and runtime middleware hooks. Neither organization has certified the three launches in this article. We use those sources to sharpen the questions, not to award compliance badges.

This table compares what is disclosed, not whether a control works under attack. The deployment boundaries are not symmetrical. A routed gateway can govern traffic that goes through it; a client hook depends on the supported client and the hook's placement; an evidence record proves only what the instrumented path observed and retained. Those distinctions are our inference from the vendors' documented architectures, not a performance measurement.

Nightfall's announcement calls MCP Gateway a governed proxy that intercepts tool calls before execution and brokers credentials so the agent does not handle the raw upstream secret. It also presents server visibility and command-line transfer protection as adjacent capabilities. The linked gateway guide makes their separation much clearer: the gateway is a hosted remote MCP path; local stdio inventory belongs to Server Visibility, and command-line transfer controls are a different product surface.

For the gateway itself, an administrator can block a whole server or disable particular tools. Calls routed through its endpoint are logged with user, server, tool, status, and request data. Upstream OAuth credentials can remain associated with the individual user, which matters when an investigator needs to connect an action to a real account rather than a shared token. Nightfall's documentation also says the backend tool response is not retained in the gateway audit view.

The same guide states two limits a buyer should test rather than bury in a footnote. The gateway does not proxy local stdio servers, and it does not prevent someone from putting a vendor URL directly in a local client configuration. It governs the sanctioned path that uses Nightfall's setup URL. Newly discovered tools are enabled after a refresh, so an administrator must review write and delete capabilities as the upstream server changes. This is not evidence that Nightfall is uniquely unsafe; it is a concrete reminder that routing coverage and tool-catalog change management are part of the control. Ask for a demonstration using both an approved remote server and a direct or local path, then verify which event appears in each product's audit surface.

Nightfall says MCP Gateway is in early access. The documentation adds that a tenant must be provisioned before its console tab becomes usable. “Available for early access” therefore should not be rewritten as “generally available to every customer.”

Lumos says its MCP Governance makes an allow-or-deny decision through a hook before a supported agent executes a tool call. Its technical post expressly says it does not route all traffic through one MCP proxy. That difference matters: a hook can observe locally added MCP servers and, according to Lumos, supported shell, file, and browser tool calls inside the client. A remote MCP gateway cannot discover every local path simply because it has a list of approved remote servers.

The launch also names its current scope: Claude Code and Codex, with other agents to follow. “Every tool call” on the product page should be read inside that supported-client boundary. A team running a different client, a custom agent harness, or direct API calls would need to verify integration coverage rather than assume the same hook is present.

Lumos says call history includes tool details, human identity, and policy decisions. Its product FAQ adds an important data-handling distinction: arguments are stored by default but can be turned off, while prompts, model responses, and tool results are not stored there. That is a more useful procurement question than asking whether the product “has logging.” Which inputs are retained, who can query them, how long do they persist, and can sensitive arguments be excluded without losing the evidence needed to investigate a denial?

The company says the product is available now for teams running the two named clients. We have not installed it or measured its advertised latency or prevention rate. Those remain vendor claims until tested in the buyer's environment.

Traefik's launch ties three ideas together: narrowing an agent's delegated authority, enforcing policy before forwarding a tool or API request, and preserving a record that another party can verify later. Its announcement names both the agent's MCP call and the tool's backend API call. That second boundary matters when a tool looks harmless by name but ultimately changes a customer record or moves money through an API.

The product overview also draws a useful line between an operational trace and an audit record. It says the gateway records allowed and refused decisions, connects them to the policy and identity involved, and commits fingerprints to an append-only log with an independently witnessed checkpoint. Those are architectural claims about record integrity. They do not independently prove that every agent path was routed through the gateway or that the business action completed as intended; the product page itself says the backend remains responsible for transaction correctness.

Availability needs careful wording. The September 15 release said general availability was planned for September 30. On September 28, Traefik's product page described Delegate, Authorize, and Prove as available on an early-access release train, with production tooling for the verifier still to follow. A product team should check the exact build, standards-draft dependency, and support terms before using “GA” in its own evaluation document. We found no public basis to claim the planned date had already arrived.

Start with an action that can change real state, such as editing a support ticket, deleting a test record, or modifying a feature flag in a non-production environment. Then draw the entire path: person to agent, agent to tool, tool to backend, and backend to durable business record. A diagram that stops at the MCP call leaves the last and often most consequential hop untested.

For each proposed control, run a short, observable evaluation:

1. Attempt the same action through approved and alternate paths. Try the sanctioned remote MCP connection, a local server if supported, and any direct connector the organization already permits. Record which path the product can see and block.
2. Change the available tool list. Add or expose a write capability in the test server. Check whether the new tool is allowed by default, needs review, or inherits an existing policy. This is especially important when a server updates itself.
3. Test identity and delegation. Confirm the log names the human, the agent or client, the upstream account, and the permission actually used. Do not infer least privilege from the presence of OAuth alone.
4. Prove a refusal and a completed action. Look for the policy decision, request arguments, timestamp, downstream API result, and retained record. A refusal at the gateway is not the same as evidence that the backend never changed.
5. Check the evidence boundary. Ask what is stored, what is sampled, who can alter or delete it, and whether another team can independently verify it later. Also test what happens when the policy service is unavailable.

NIST's agent-identity questions and OWASP's runtime-control framing make these tests timely, but they are not a substitute for a buyer's own threat model. Different teams will value different controls: a developer-heavy organization may begin with local tool visibility; a centrally managed platform may prioritize a routed gateway; a regulated workflow may also require a separately verifiable decision history.

For a SaaS product team or agency tracking this category, a competitor feature-release workflow should capture changes to supported clients, enforcement mode, default tool policy, documentation, and availability—not just the launch headline. A competitive intelligence dashboard can show which claims changed and where; a competitive intelligence report can separate the observed product-page edit from the conclusion a buyer should test.

We read public pages, not product binaries, contracts, customer configurations, or private roadmaps. The vendors chose what to publish. Documentation can change after September 28, and a missing public detail is not proof that a capability does not exist. Three launches cannot establish a market-wide adoption rate, a security outcome, or which architecture is best. We did not conduct penetration tests, measure latency, validate audit-log integrity, or obtain independent customer evidence for any vendor.

The source set is reproducible at the URL level but not historically frozen: the pages may be edited. To extend the study, archive the announcement, docs, and product page for each vendor on one collection date; publish the exact coding sheet; include vendors with different architectures; and test a standard action and bypass case in controlled environments. Until then, our finding is a comparison of disclosed boundaries, not a benchmark of protection quality.