Gated release lane for security-capable AI: ship, prove, ask
A release lane for security-capable AI: define a public baseline, gate the defender variant, and require independent evidence before workflows change.
| By | Prompt & Product — Newsroom |
|---|---|
| Filed | 10 September 2026 |
| Read | 4 MIN |

You are deciding who can run a security-capable model, what proof it needs, and when users may change their workflow. Gemini 3.8 Flash Cyber is not offered via the standard Gemini API; access is limited to vetted defenders under Google's Fairwind Program, including public agencies, operators of essential infrastructure, and software maintainers. The redesign is a lane: a public baseline, a gated defender variant, and independent evidence before workflows change. Make the lane the product, not the model card.
The public baseline must be inspectable
Define the public baseline as the evidence any team can inspect without special access. The finished state is a named model, a documented capability boundary, and a public eval that shows where it is strong and where it is not.
Run the baseline against a shared security task set. Use CWE-Bench, a vulnerability benchmark, when the task is vulnerability detection. Gemini 3.8 Flash Cyber achieved 47.2 percent pass@1 on CWE-Bench, while a leading frontier model achieved 47.8 percent. Keep a dated record of the score, the task set, and the failures.
Add a general capability score so the baseline is not only a security number. Gemini 3.8 Flash achieved a 54.9 percent score on HLE-Verified. A public number only matters when the reader can reproduce the task, the metric, and the failure mode.
Name the capability boundary in plain language. The boundary should say what the model can inspect, what it can change, and what it must not do. It should be a short description that a non-security engineer can read without asking for a glossary.
Set the eval cadence before launch. Run the same task set after each model update, each prompt change, and each access change. Done means a dated record that shows whether the baseline still holds.
The defender variant must be a contract
Gate the defender variant behind access controls that match the risk. The gate needs an application process, a named program, and a list of who is allowed to use the capability. The record is a request that cannot bypass the program.
Require independent evidence before the gated variant changes a workflow. The evidence package includes third-party evals, patch correctness checks, and a cost model that survives production volume.
Check the evidence against the job. On an internal benchmark spanning 20 programming languages, the model exceeded a 70 percent success rate for discovering vulnerabilities in complex codebases. The model generated 2.6 times more correct Chrome vulnerability patches than much larger top commercial models. On Wiz's internal penetration-testing benchmark, it showed 7.5 to 9.7 percent higher recall while costing 2.3 to 5.2 times less than other leading frontier models. The deliverable is a decision memo that names the gap.
Write the access contract before any request. The contract should name the allowed use, the data scope, the retention limit, and the exit path. It is a document both parties can point to when a request falls outside the lane.
Test the gate under pressure. Ask for a capability the lane does not cover and watch the refusal. The refusal is a clear denial, a reason, and a path to request the right tier.
If a team can say defender-grade without showing the eval, the lane has failed.
Cost and access are trust signals
Price the lane so the tier is visible. Introductory rates are $0.75 per million input tokens and $3.75 per million output tokens through December 31, 2026, rising to $1.50 and $7.50 per million tokens on January 1, 2027. The price table is the first trust signal a buyer sees.
A gated lane that hides pricing, access, or evals asks users to infer the boundary. A lane that shows the boundary lets them decide.
Label the active tier in the interface. The label should say which variant is running, what it can do, and what evidence supports the claim. It gives a new user a quick check that the tier is real.
Log the boundary. Record who requested access, what data the model can see, and what the user was told. The audit trail is the done state.
Estimate the production volume before the price is a surprise. Count the expected number of code files, the average token length, and the number of retries. The cost range is a monthly number with an owner, not a demo run.
Assign a budget owner. That person should see the cost trend, the access list, and the eval results in the same place. The owner can answer whether the lane is still worth the tier.
Receipts must precede workflow changes
End the release plan with a checklist that the team can sign. Each item needs an owner, a date, and a receipt.
- public baseline
- gated defender variant
- independent evals
- patch correctness
- cost
- access controls
- user-facing trust signals
Ship only when each item has a receipt.