Gemini 4 Argon access: What Google's Fairwind rules require

Fairwind is Google's limited-access program for cyber defenders. Organizations that pass Google's vetting get early access to Gemini 4 Argon with its cyber guardrails switched off, in exchange for strict rules on who inside the organization can use it and how that use is recorded.

Google announced Gemini 4 Argon on September 30. Developers do not get it yet. Paid API customers and Google AI Ultra subscribers are queued behind a cohort of cyber defenders admitted through Google's Fairwind Program, and those defenders get a build nobody else will. From the announcement:

"For trusted defenders and our own internal teams at Google, we'll be releasing Argon without cyber guardrails so they can leverage its full frontier-level cybersecurity defense capabilities."

The Verge headlined it "Google announces Gemini 4, restricts access to 'trusted cyber defenders'," and the Hacker News thread passed 1,600 points and 1,100 comments. Nearly all of that argument was about benchmarks. The document worth reading twice is the eligibility list.

Fairwind's published governance rules describe an authorization system. Google verifies the applying organization, dictates an authentication posture for that organization's users, restricts the grant to specific internal teams, and requires the customer to keep a record of who used it. Swap the words "frontier model" for any gated capability and you're looking at an enterprise entitlements spec.

Who can access Gemini 4 Argon?

Fairwind launched on September 2 as "a limited access program for governments and trusted partners to use our cyber defense tools," starting with Gemini 3.8 Flash Cyber paired with Google's CodeMender agent. Google says it has more than 650 participating partners globally, with priority for governments and national cyber authorities, critical infrastructure operators, and core technology platforms. Gemini 4 Argon is now the program's exclusive model, usable standalone or inside CodeMender.

Then the governance terms take over. On due diligence, the Fairwind program page says Google runs background checks on applying organizations to verify their security history and record of ethical operations. And on what the organization has to do once it's in:

"Participating organizations agree to specific terms, including user-level authentication, phishing-resistant MFA, and applicable access controls. Organizations may only grant Gemini 4 Argon access to internal cybersecurity, incident response, or penetration testing teams, and must track employee access and use."

Two more constraints sit beside those. Partners cannot share, redistribute, or sell access to the models. And the grant only covers a named list of uses: "authorized threat simulation, reverse engineering, and malware analysis for defensive and academic research purposes."

How do Fairwind's rules map to identity primitives?

Every one of those clauses has a name in identity terms.

‍

Google doesn't present any of this as identity work, and from Google's side it's probably a contract with a technical appendix. But every clause gets enforced somewhere in a system that knows which organization a request belongs to, which employee made it, how that employee authenticated, and whether they sit on the security team. That is a directory with a policy engine on top of it and an audit log underneath. In code, the gate in front of each call looks something like this:

  
const PHISHING_RESISTANT = new Set(["webauthn", "passkey", "fido2_key"]);
const ALLOWED_ROLES = new Set(["security", "incident_response", "pentest"]);

async function canInvokeUnrestrictedModel(req: Request) {
  const session = await getSession(req);              // user, org, auth factor
  const org = await getOrganization(session.orgId);

  return (
    org.verified &&                                    // org vetting passed
    org.entitlements.includes("cyber_unrestricted") && // tier granted to the org
    PHISHING_RESISTANT.has(session.authFactor) &&      // MFA posture enforced
    session.roles.some((r) => ALLOWED_ROLES.has(r)) && // team restriction
    session.user.active                                // still in the directory
  );
}
  

What does the guardrail flag actually switch?

The guardrailed Argon and the unguardrailed Argon are the same model with different refusal behavior. Cyber Kendra put the tension plainly: the safety section of Google's announcement says Argon is designed to refuse requests to help with cyberattacks, "while the same post confirms those refusals are switched off for the defenders receiving it first." Google ties its safeguards to its Frontier Safety Framework and says it will keep gathering early-tester feedback while it strengthens them before a broad release.

That makes this entitlement unusually load-bearing. A typical feature flag decides what a customer can see. This one decides what the system is willing to do on a customer's behalf. According to the figures Cyber Kendra reported, Argon scores 85.8% on vulnerability discovery against 71.0% for Gemini 3.8 Flash Cyber, and 70.9% on penetration testing against 58.2%. Google's own post has it tied for first on CWE-bench v1 at 68%, and says the model "uncovered a critical vulnerability exposing sensitive personal information across healthcare software used by hospitals worldwide," one that previous frontier models had missed.

Grant that to the wrong tenant and you have handed someone a frontier-grade vulnerability discovery engine with the refusals turned off.

Who has to keep the audit trail?

The clause I keep rereading is the last one: organizations "must track employee access and use." Google verifies the organization and then hands per-employee record-keeping to the partner. Any customer that signs those terms now has to answer, on demand, which of its people touched a frontier cyber model and when.

Most teams can't answer that from their application logs. A usable answer needs a documented event schema carrying real actor context (user ID, session ID, IP, user agent, region) so an investigator can reconstruct a sequence instead of guessing at one. Roughly this shape, per call, which is the kind of structured event a product like WorkOS Audit Logs is built to store, search, and export:

  
{
  "action": "model.invoke",
  "occurred_at": "2026-10-01T09:14:22Z",
  "organization_id": "org_01HQ...",
  "actor": {
    "type": "service_account",
    "id": "sa_codemender_runner",
    "on_behalf_of": "user_01J2...",
    "session_id": "sess_01J2...",
    "ip": "203.0.113.17",
    "user_agent": "codemender/2.4",
    "region": "us-east"
  },
  "targets": [{ "type": "model", "id": "gemini-4-argon" }],
  "context": { "entitlement": "cyber_unrestricted", "role": "incident_response" }
}
  

The on_behalf_of field is the one that matters here. The model is often driven through a harness like CodeMender rather than a chat box, so the actor on the wire is usually a service account, and an audit trail that only records human logins will not answer Google's question. Deprovisioning should land in real time instead of overnight for the same reason: a defender who moves off the security team should lose the entitlement the moment the directory says so.

Where does organization-level vetting fall short?

The strongest objection to reading Fairwind as access control is that it's a safety program wearing legal clothes, and the identity framing overfits. The rules answer that themselves. A contract can forbid resale; only an identity system can tell you that every user holding the entitlement authenticated with a phishing-resistant factor and belongs to the incident response team.

The design does have gaps, and they're the familiar ones.

Vetting is point in time. The background check happens when the organization applies, and the entitlement persists afterward. A partner that passes diligence this month and suffers a ransomware attack next year still holds its Argon grant. Nothing Google has published describes what triggers a re-review, and an organization's security record is exactly the sort of attribute that changes after a breach or an acquisition.

Organization granularity doesn't match misuse granularity. A vetted partner is a population of employees, which is presumably why Google stacks per-user MFA, team restriction, and usage tracking on top of the org check. Each of those layers gets enforced inside the partner's own systems rather than Google's.

The perimeter is opaque. Google hasn't published a list of Fairwind participants, so a partner can't evaluate the trust boundary it just joined. The downgrade path, at least, is explicit: organizations that don't qualify can still use CodeMender with publicly available models alongside other Google AI Threat Defense products, and Argon supports zero data retention when accessed through Gemini Enterprise. Published tiers with published fallbacks beat the case-by-case exceptions that most trusted-customer programs turn into when they get built ad hoc.

How do you build a trusted-customer tier?

Fairwind's terms read well as a requirements list.

1. Verify the organization, not the signup. Domain ownership proved with a DNS TXT record is the cheap version of a background check, and it's the gate that stops a random employee from claiming authority over their company's tenant.
2. Make the entitlement per organization. Each tenant already carries its own SSO and SCIM configuration, policies, and admins, so capability grants belong in that same record.
3. Require the authentication posture rather than recommending it. Admins need to enforce MFA, ideally across a whole organization and often per role, with WebAuthn and FIDO2 keys as the real option and SMS treated as the legacy fallback it is.
4. Scope the grant to a role. A user who is an admin in one tenant and a viewer in another is the normal case, and the authorization model has to represent that natively.
5. Log the grant and the usage, with actors, in an audit log you can export: who was granted what, by whom, and who then used it.
6. Revoke on the directory's timetable. Real-time deactivation through directory sync webhooks, not nightly reconciliation.
7. Hand the controls to the customer's admin. A self-serve portal turns a multi-week onboarding engagement into something an IT admin finishes themselves.

None of that is new work. It's domain verification, MFA enforcement, RBAC, Directory Sync, and Audit Logs, the same stack that AI companies already selling into enterprises run on, WorkOS customers among them.

Google spent most of the Argon launch on capability: a 1M-token output limit, up from 64K, and an introductory price of $2 per million input tokens and $10 per million output tokens. The more reusable artifact is the governance page. It is one of the clearest public descriptions of a frontier-model capability tier keyed to verified organizational identity, and every clause in it is something a team has to implement. If a trusted-customer tier is anywhere on your roadmap, read Fairwind's terms as a spec rather than a press release. The first time a partner has to produce its employee access record, the answer will come from a log or from somebody's memory, and only one of those survives the review.