Fugu-Cyber hides its model route. Can your security policy allow that?

Fugu-Cyber presents a direct policy mismatch. Sakana AI announced the service on July 21, 2026 JST as a new cyber API endpoint: the customer sends one request, receives one answer, and gets token usage and cost for that request. The customer cannot see which underlying model or models handled the query.

That missing identity can decide whether a security team may send source code, vulnerability details, incident evidence, or threat intelligence to the endpoint. This article separates the facts and controls Sakana publishes from the terms a buyer still needs, then explains what the benchmark scores establish and when the route can be approved.

Fugu-Cyber exposes one endpoint while keeping the answering models private

The Fugu product page describes Fugu as a multi-agent system delivered as one model. A multi-agent system assigns parts of a task to several AI agents and coordinates their work. Sakana says the Fugu family includes Fugu, Fugu Ultra, and Fugu Cyber through one OpenAI-compatible API, which means existing clients can use the familiar OpenAI request format without an SDK migration. Compatibility does not make OpenAI the service provider or import OpenAI's data terms.

Fugu-Cyber specializes that system for security analysis, vulnerability research, and threat investigation. Sakana says it dynamically orchestrates a pool of specialized agents for a request while presenting the result as a single model response. The route is the set of underlying models, providers, assignments, and coordination steps that produced that response.

The product FAQ answers the attribution question directly:

Example

“No. The specific models Fugu selects and how it coordinates them are proprietary, so this routing information is not exposed by design.”

Sakana has made this a firm product boundary. A buyer can know that the request went to Fugu-Cyber and how many tokens it used, yet still lack the requested-model, answering-model, and fallback evidence that a model-specific policy may require. Our earlier analysis of Claude Fable 5 routing policy assumed that those route facts should be logged when available. Fugu defines a different limit: per-query model attribution is unavailable to the customer.

Attribution matters in security work because permissions often attach to a named provider or model. Contract terms, data residency, retention, safety filters, tool access, and approved uses can differ across participants in an AI service. If a vulnerability-analysis request can reach any member of an undisclosed pool, the team must either approve the whole endpoint under one enforceable set of terms or keep the data out.

Per-request cost reporting solves a narrower problem. Sakana's FAQ says token usage and cost are reported for each request, which supports spending review and anomaly detection. A bill tied to a query does not identify which models received its data or which agent produced a material finding.

The public controls do not establish a Fugu-Cyber provider boundary

Sakana publishes several useful product facts. Fugu-Cyber is available on the Token Plan after an applicant describes the intended use, provides verified contact information, and passes manual review. The release also says an updated acceptable-use policy prohibits offensive misuse. Those controls govern access to the service; they do not disclose the service's internal route.

The public product and FAQ pages establish the following boundary:

Scroll sideways to see all 3 columns.

Area	What Sakana publishes	What it means for approval
Interface	Fugu, Fugu Ultra, and Fugu Cyber use one OpenAI-compatible API.	Integration can stay familiar, but security terms still come from Sakana and its service chain.
Request accounting	Token usage and cost are reported per request.	The buyer can monitor consumption, not underlying model identity.
Training use	Customers can opt out of training-data usage in the console.	The opt-out addresses training use only. It does not establish zero retention, no logging, no subprocessors, or no other data processing.
Region	Fugu is not available in the EU or EEA.	EU and EEA teams cannot treat the public offer as available to them. Other teams still need applicable location and transfer terms.
Model control	Ordinary Fugu users can opt specific models out. Fugu Ultra has a fixed pool.	The page does not state that Fugu-Cyber has model or provider opt-outs. Cyber pool membership and opt-out controls remain unresolved.
Route disclosure	The selected models and coordination are not exposed for each query.	A policy that requires per-query model identity cannot be satisfied with public Fugu telemetry.

The distinction in the model-control row is easy to miss. The general product copy promotes agent selection, but FAQ Q3 assigns that control to ordinary Fugu and explicitly says Fugu Ultra's pool is fixed. Neither passage gives Fugu-Cyber customers the same option. A buyer should obtain a Cyber-specific answer rather than carrying an ordinary Fugu feature across product lines.

The displayed Fugu-Cyber Token Plan rates are $6 per million input tokens, $36 per million output tokens, and $0.60 per million cached input tokens. For context above 272,000 tokens, the displayed rates rise to $12 input, $54 output, and $1.20 cached input. These prices make a scoped evaluation budget possible, but they reveal nothing about the number, identity, or commercial terms of the agents behind a request.

Several approval facts remain absent from the reviewed public pages. They do not identify the Fugu-Cyber pool, establish whether that pool can change without notice, or state a Cyber-specific provider allowlist or opt-out. They also do not establish retention periods, zero-retention eligibility, the complete subprocessor chain, processing locations, deletion behavior, or the relationship between Sakana's training opt-out and other operational uses of request data.

Some of those facts can be resolved in contracts, security documentation, and a completed privacy review even when the per-query route stays private. The buyer then needs one endpoint-level commitment that covers every potential participant. If different pool members carry different data terms and the customer cannot identify which one handled a request, a provider-specific approval cannot be enforced after the fact.

The benchmark results show task performance, not a production security record

Sakana reports an 86.9% success rate on CyberGym and 72.1% on CTI-REALM. Both are relevant security evaluations, but they test different work and neither score is an independent production outcome for Fugu-Cyber.

CyberGym contains 1,507 instances drawn from historical vulnerabilities in 188 software projects. Its primary task gives an agent a vulnerability description and an unpatched codebase, then checks whether the agent can produce a working proof of concept, or PoC, that triggers the vulnerable build and does not trigger the patched build. The benchmark therefore measures concrete vulnerability reproduction under its test conditions.

At the July 21 snapshot, the live CyberGym leaderboard did not list Fugu-Cyber. It listed Crystalline at 89.6%, MDASH at 88.45%, and GPT-5.5-Cyber at 85.6%. Sakana compares its multi-agent endpoint with cybersecurity-focused frontier models, while CyberGym's combined leaderboard includes both model-focused and agent-focused submissions. Without a listed Fugu-Cyber submission and identical run details, 86.9% supports Sakana's capability claim but does not yield a simple public rank or an independently reproduced winner.

The CyberGym FAQ adds an important test-integrity caveat. Network access can let an agent retrieve a published patch or PoC and receive credit without solving the intended task. The maintainers recommend restricted egress and inspection of the agent trajectory, meaning the record of its actions, to check for that shortcut. A buyer evaluating Fugu-Cyber should ask about network access and inspectable traces before treating the score as evidence of autonomous vulnerability reasoning.

CTI-REALM evaluates a different workflow: turning public cyber threat intelligence into validated detection logic. Microsoft describes 37 public reports and 50 tasks across Linux, Azure Kubernetes Service, and Azure cloud environments. Agents read reports, explore telemetry, refine Kusto Query Language queries, and produce Sigma rules and Kusto-based detections.

Sakana's 72.1% result cannot be compared directly with historical CTI-REALM scores unless the benchmark version, agent harness, tools, reasoning settings, task budget, and scoring method match. The same model can produce a different result when its tools or call budget change, as our discussion of AI model bake-off harnesses explains. The reported score shows performance in Sakana's configuration; it does not isolate the contribution of any hidden model or predict a buyer's environment.

Neither benchmark establishes a false-positive rate on production findings, the analyst time needed to review them, patch safety, latency under operational load, or the quality of detection rules after deployment. No named customer, deployment count, independent production result, or measured analyst workload was verified in the reviewed sources. Early Hacker News discussion, with five points and one comment at the research snapshot, adds no credible adoption or performance evidence.

Sakana itself says raw models can produce false positives. The company calls for security-specialized sub-agents and human confirmation that a vulnerability would trigger in the real environment before anyone proposes a patch. The statement supports requiring review, but it provides no evidence that Fugu-Cyber deployments have achieved the stated review quality. Security teams still need the evidence acceptance, containment, and analyst-verification controls described in our guidance on AI and exploit-rich incident evidence.

Approval is reasonable only when policy can govern every hidden route as one service

A security team can approve Fugu-Cyber for a defined use if its policy permits endpoint-level approval. Procurement and privacy review would need enforceable terms covering every model and provider that may process a Cyber request, even if Sakana does not reveal the selected member for each query. Those terms should settle the subprocessor chain, processing locations, retention and deletion, training and other data uses, incident obligations, pool-change notice, and the availability or absence of Cyber-specific opt-outs.

The approved data class must be safe for every possible route. A team might authorize public threat reports or sanitized test repositories before it authorizes proprietary source code, live telemetry, credentials, personal data, or incident evidence. Removing secrets before submission remains necessary because no routing term makes a credential appropriate model input.

Operational approval should name the use and data class behind the API key. For vulnerability analysis, the endpoint may draft or reproduce a finding while a security engineer confirms reachability, exploit conditions, affected versions, and patch behavior. For threat intelligence, an analyst should test proposed rules against representative telemetry and review false positives before deployment. Fugu-Cyber should not merge a patch, change a detection, or trigger containment solely on its own answer.

A local evaluation also needs comparable conditions. Run the proposed Fugu-Cyber workflow against the current method with the same inputs, tools, network policy, call budget, time limit, and acceptance criteria. Preserve the endpoint configuration, source references, request time, token and cost report, output, tool effects, and reviewer decision. That record cannot recover the hidden model route, but it can show what the approved endpoint did and why a human accepted or rejected the result.

Defer approval when policy requires the identity of every answering model, a per-query provider record, or the ability to exclude unapproved models and providers. Sakana says the route is hidden by design, and the public product page does not establish a Cyber-specific opt-out. Defer as well when the organization lacks contractual answers for retention, subprocessors, processing locations, pool changes, or deletion, or when procurement requires independent production evidence that the current public record does not contain.

This can produce a narrower decision than a company-wide yes or no. An organization can approve sanitized benchmark work while withholding production code and telemetry. It can approve analyst assistance while prohibiting autonomous remediation. Scope is useful only when technical controls prevent broader data and actions from drifting into the endpoint.

BaristaLabs can review one cyber-AI endpoint against its data route, provider policy, benchmark evidence, and human verification boundary, with the review anchored in data security.

Approve Fugu-Cyber only if your organization can approve an endpoint-level service whose hidden route is contractually covered and operationally contained. If your policy requires model identity or a model or provider opt-out, defer: Sakana says the route will remain hidden, and its public materials do not establish a Cyber-specific way to narrow it.