Griffin 3.0 is now generally available across US, EU, and Gov regions of Safeguard.sh. Griffin is the reasoning and remediation model that sits behind most of the interactive surfaces in the product — the web app, the desktop application, the IDE extensions, the MCP server, and the Local Runner. Where Eagle classifies and Lino maps to compliance controls, Griffin is the one that plans, edits, and explains.
This is a working release rather than a marketing one. We moved from 2.5 to 3.0 because the planner, the tool-use loop, and the remediation format all changed in ways that you will notice if you were already using 2.5 in production. This post walks through what changed, what we kept, and the defaults you should double-check before you roll 3.0 out to a large team.
What actually changed between Griffin 2.5 and 3.0?
The short version: Griffin 3.0 is a new planner on top of a larger base model, with a reworked tool-use loop and a longer effective context window. It is not a fine-tune of 2.5.
Three things changed materially. First, the planner now produces an explicit plan-of-record before it touches code, and every subsequent tool call is tied to a plan step. This replaces the freer "think-then-act" pattern in 2.5 and is the reason remediation runs are now resumable. Second, the tool-use loop can recover from a failed step by re-planning against the same objective rather than abandoning the run, which was the single largest source of flaky remediation PRs in 2.5. Third, the effective context window for a single reasoning turn is now 400K tokens, which means Griffin can hold a full reachability graph for a medium-sized Node or Python service in-context instead of streaming it in chunks.
There are smaller changes worth flagging. Griffin 3.0 emits structured remediation plans in a versioned JSON schema (griffin.plan/v3) rather than free-text plus a diff. The diff is still there — it is now an attachment on the plan, not the plan itself. Tool definitions now use typed output schemas, which means downstream consumers (CI, the web app, your own scripts) can rely on shapes instead of regex-parsing prose. And the refusal behavior for destructive actions has been tightened; Griffin 3.0 will not rewrite lockfiles, delete files, or force-push without an explicit capability grant in the workflow that invoked it.
How does the new planner behave in a real remediation run?
Answer first: it plans, asks for approval on non-reversible steps, then executes, and every step lands in an audit trail you can replay.
A typical run against a CVE in a transitive npm dependency looks like this. Griffin ingests the finding from Eagle, pulls reachability data from the workspace, and produces a plan with three or four steps — something like "pin the direct dependency to a version whose transitive closure removes the vulnerable package, update lockfile, run the test subset that touches the reachable call sites, open a PR." Each step has a requires_approval flag. Lockfile writes and branch pushes always require approval in the default policy; test runs and read-only analysis do not.
When a step fails, 3.0 does not stop. If the npm install step fails because the pinned version conflicts with a peer dependency, Griffin re-plans from the failure point, tries the next viable version in the SemVer range, and records both attempts in the run log. You can inspect the run afterward in the web app or via safeguard run show <run-id> and see the full plan tree, not just the final diff.
{
"plan_version": "griffin.plan/v3",
"objective": "Remediate GHSA-xxxx-xxxx-xxxx in service-api",
"steps": [
{ "id": "s1", "kind": "analyze", "requires_approval": false },
{ "id": "s2", "kind": "edit.package","requires_approval": false },
{ "id": "s3", "kind": "write.lockfile","requires_approval": true },
{ "id": "s4", "kind": "test.subset", "requires_approval": false },
{ "id": "s5", "kind": "git.push", "requires_approval": true }
]
}
If you were writing custom workflows against 2.5 and parsing free-text plans, this is the change that will affect you most. The migration is mechanical but real.
What is the behavior on ambiguous or unsafe fixes?
Griffin 3.0 is more conservative than 2.5 on three classes of changes, and the defaults reflect what we heard from teams running 2.5 in production for a year.
It will not perform a major-version bump as part of a CVE remediation unless the workflow explicitly permits it. In 2.5, a major bump was allowed when no safe minor existed; in 3.0, the default is to open a PR with the minor-bump attempt plus a note describing the major-bump option, and let a human choose. This is the single biggest behavioral change and the one most likely to break existing automation. If you want the old behavior, set allow_major_bump: true on the remediation workflow.
It will not modify CI configuration, IAM policy files, or anything under a .safeguard/ or .github/workflows/ path without an explicit capability. This is a new default in 3.0 and applies to the MCP server and Local Runner as well. And it will refuse to touch files that appear in a secrets scan result from Eagle — if there is a credential in a file, Griffin declines to edit that file at all and surfaces the finding instead.
The refusal format is structured. You get a refused step with a reason_code (for example policy.no_secret_edit, policy.major_bump_not_allowed, capability.missing) that you can key off in automation.
Does it work with the rest of the platform?
Yes — 3.0 is the default model everywhere Griffin was already available, and the older versions remain callable by name for a grace period.
Concretely: the MCP server exposes Griffin 3.0 to Claude Desktop, claude.ai, Claude Code, ChatGPT, Cursor, Gemini, and Grok with no client-side change. The IDE extensions for VS Code, Cursor, and the JetBrains family pick up 3.0 automatically on next launch. The desktop application on macOS, Windows, and Linux ships with 3.0 as the default reasoning model. The Local Runner — which runs an agent loop on your laptop and can edit your working tree — defaults to 3.0 for remediation workflows and to Eagle 3.0 plus Lino 2.0 for classification and compliance.
For customers in FedRAMP HIGH, IL7, and SOC 2 Type II environments, Griffin 3.0 is validated and available in the Gov region alongside the commercial regions. The model is the same; the data boundary is different.
If you need to pin an older version for reproducibility — we see this for customers with change-control windows — you can do so per-workflow:
# .safeguard/workflows/remediate-cve.yml
model:
griffin: "3.0" # or "2.5", "2.0" during the grace period
eagle: "3.0"
lino: "2.0"
The grace period for 2.5 is six months. After that, pinning to 2.5 will continue to work for on-prem and Gov deployments but will be flagged in the web app as unsupported.
How Safeguard.sh Helps
Griffin 3.0 is the reasoning layer for the whole platform, so the upgrade propagates automatically: the MCP Server, the desktop application, the Local Runner, the IDE extensions for VS Code, Cursor, and JetBrains, and the web app at app.safeguard.sh all pick up the new planner and tool-use loop without client changes. When Griffin proposes a remediation, it is working against real signal — Eagle 3.0 classification, Lino 2.0 compliance mapping, reachability analysis that cuts 60-80% of CVE noise, and the Gold Registry's 6,000+ zero-CVE packages as a pin target. The structured plan format and typed tool outputs make it straightforward to integrate Griffin runs into existing CI, and the FedRAMP HIGH, IL7, and SOC 2 Type II validations mean the same model is available in regulated environments without a parallel rollout. If you are already running Safeguard, the 3.0 rollout is a config bump plus a workflow review for the behavioral changes described above.