feat: switch bitwarden-security-engineer to Claude Fable 5

[withinfocus]

🎟️ Tracking

Introducing Claude Fable 5 and Claude Mythos 5 — Anthropic's Mythos-class model, generally available 2026-06-09.

📔 Objective

Switch the bitwarden-security-engineer plugin from Opus to Claude Fable 5, which has stronger software-engineering and security-analysis capability (the announcement highlights its vulnerability-discovery performance).

Changes

• bitwarden-security-engineer agent: model is now fable.
• perform-security-review skill: the four review agents + verification agent now default to fable; the --model override is unchanged.
• Version bump 1.2.0 → 1.3.0 (marketplace.json, plugin.json, README catalog) + CHANGELOG entry.

Model identifier note

Used the fable shorthand in frontmatter (matching the existing opus/sonnet/haiku convention). The official model docs list only the canonical API ID claude-fable-5 — there is no separately documented fable API alias — so if a reviewer finds fable does not resolve in their Claude Code version, swap both spots to claude-fable-5 (they resolve to the same model).

Safeguard behavior (intentional, documented)

Fable 5 carries built-in safeguards for high-risk domains including cybersecurity, and falls back to Claude Opus 4.8 automatically when they trigger. For this plugin's authorized, defensive AppSec work the fallback is graceful rather than a refusal; the perform-security-review skill's existing "authorized internal security engagement" framing keeps reviews on-task. This is noted inline in the skill and the changelog.

Skills review

The seven skills are model-agnostic and already follow progressive-disclosure structure; no Fable-driven rewrites were warranted. The only skill-level change is documenting the safeguard/fallback behavior where it's operationally relevant.

Validation

pnpm run lint, validate-plugin-structure.sh, and validate-marketplace.sh all pass.

[github-actions]

🔍 Plugin Validation Report

PR #142 · bitwarden-security-engineer v1.3.0 → v1.4.0

Validated with the plugin-dev plugin-validator and skill-reviewer agents, and the claude-config-validator reviewing-claude-config skill.

Verdict

All mechanical checks pass. Manifest, structure, auto-discovery, frontmatter, semver, version consistency, changelog format, file references, and credential scanning are clean, and the repo's version-bump + changelog process was followed correctly.

model: fable is a valid frontmatter value — not an error. The findings below are about the substance of the change: the accuracy of the claims added to the changelog and skill, and two undocumented failure modes the new default introduces.

Severity	Count	Type
🔴 Critical	0	—
🟠 Major	3	Warnings (should fix)
🟡 Minor	4	Warnings (should fix)
⚪ Pre-existing	5	Out of scope, noted

---

✅ What passed

Plugin structure & manifest — .claude-plugin/plugin.json is valid JSON; name is kebab-case; version 1.4.0 is valid semver; description, author{name,url}, homepage, repository, keywords all present; the agents entry resolves to an existing file. README.md and CHANGELOG.md present; no stray files.

Version consistency — 1.4.0 agrees across all four locations: .claude-plugin/marketplace.json:57, plugins/bitwarden-security-engineer/.claude-plugin/plugin.json:3, CHANGELOG.md:8, and the root README.md. No version: field in agent frontmatter, so nothing else to sync.

Changelog — Keep a Changelog format, correct ## [1.4.0] - 2026-07-29 heading, descending order, ### Changed category, and the entry describes both changed components.

Agent frontmatter (agents/bitwarden-security-engineer.md) — name is 28 chars, lowercase + hyphens; description present; color: red valid; tools and skills present; system prompt well above the 20-char minimum. model: fable is an accepted value per the sub-agents frontmatter schema (sonnet | opus | haiku | fable | <full model ID> | inherit) and is dispatchable by the Agent tool.

Skill quality (skills/perform-security-review/SKILL.md) — 1,962 words (inside the 1,000–3,000 target), imperative throughout, trigger-rich description, clear step ordering with explicit negative scoping per agent. Every referenced file exists, including the transitive chain references/security-review-rubric.md → ../../analyzing-code-security/references/framework-checklists.md, and all six Skill() targets resolve.

Security scan — No committed secrets, no hardcoded credentials, no settings.local.json, no API keys or tokens in any changed file. gh api calls are restricted to --method GET. The only credential-shaped strings anywhere in the plugin are clearly-labelled teaching fixtures in the unchanged skills/detecting-secrets/SKILL.md.

---

🟠 Major (warnings — should fix)

M1 — Fable 5 is documented as not intended for cybersecurity; this is the one plugin where that matters most

plugins/bitwarden-security-engineer/agents/bitwarden-security-engineer.md:4
plugins/bitwarden-security-engineer/skills/perform-security-review/SKILL.md:24

Anthropic's model documentation states plainly that Fable 5's safety classifiers "target research biology and most cybersecurity content" and that Claude Fable 5 is not intended for those domains; offensive-security workloads "trigger fallback frequently, often on the first request." This plugin's entire purpose is cybersecurity analysis, and the five agents it launches carry prompts saturated with vulnerability and attacker-perspective language (SKILL.md:66-76) — close to a worst case for classifier triggering.

Failure scenario. The agent previously used model: opus, which resolves to Claude Opus 5. Fable's cyber-category fallback target is Claude Opus 4.8 — an older model. So for the flagged share of this plugin's workload, the effective serving model moves Opus 5 → Opus 4.8; requests that are not flagged run on Fable at $10/$50 per MTok versus Opus 5's $5/$25. Which model produced any given finding also becomes non-deterministic, which matters for reproducibility of security-review output.

Remediation. Use model: opus (Opus 5) or pin claude-opus-5 explicitly, and keep fable opt-in via the existing --model flag. If the team wants Fable-class capability for security work, the documented path is a trusted-access program via the Anthropic account team, not a plain model: fable pin. This would also restore consistency with the other six agents in the repo, all of which use model: opus.

If the team accepts this tradeoff deliberately, say so explicitly in the changelog rather than describing it as a capability gain.

M2 — Changelog overstates Fable 5's security-analysis capability

plugins/bitwarden-security-engineer/CHANGELOG.md:12

"…with stronger software-engineering and security-analysis capabilities."

The software-engineering half is supportable. The security-analysis half is contradicted by Anthropic's own model documentation, which states Fable 5's bug-finding and code-review gains explicitly exclude security-focused analysis, precisely because the cyber classifiers apply there.

Remediation. Drop "and security-analysis", or replace with an accurate statement of the tradeoff (stronger general SWE capability; security-flagged requests re-route to Opus 4.8).

M3 — Fable 5 requires 30-day data retention; this prerequisite is undocumented

plugins/bitwarden-security-engineer/skills/perform-security-review/SKILL.md:24

Claude Fable 5 is not available under zero data retention — requests from an org whose retention configuration doesn't meet the requirement return 400 invalid_request_error on every call. For a Bitwarden-maintained security plugin that reads private diffs, ZDR is a plausible org posture, and such an org would see every one of the five agents fail with no hint that retention is the cause. Nothing in SKILL.md, CHANGELOG.md, or the plugin README.md mentions this.

Remediation. If the fable default stays, add to the model-selection paragraph: "fable requires the organization to allow 30-day data retention; under zero data retention every request returns 400. Pass --model opus in ZDR environments."

---

🟡 Minor (warnings — should fix)

m1 — "built-in cybersecurity safeguards" misattributes the fallback mechanism

CHANGELOG.md:14, SKILL.md:24

The automatic fallback is real in Claude Code — the harness re-runs classifier-flagged requests on Claude Opus 4.8 — so the described behavior is broadly accurate for agents launched inside Claude Code. Two corrections:

• The fallback is an escape from Fable provided by the harness, not a Fable 5 feature. "Built-in cybersecurity safeguards" frames a classifier decline as a capability.
• It is not automatic on the Claude API, where fallbacks are opt-in (fallbacks parameter plus a beta header). Anyone reading this line as a general property of Fable 5 will be wrong outside Claude Code.

Suggested wording: "Claude Code automatically re-runs cybersecurity-flagged Fable 5 requests on Claude Opus 4.8, so authorized defensive reviews degrade gracefully rather than refusing. (This fallback is a Claude Code behavior; it is opt-in on the Claude API.)"

m2 — Prompt framing is presented as a classifier mitigation

SKILL.md:24

"…the authorized-engagement framing required in step 2 keeps this defensive review on-task."

Classifiers evaluate the request server-side; text inside the prompt does not disable them, and the docs describe flagging in this domain as expected routing rather than something framing prevents. Delete the clause, or restate it as scope-setting for the agent rather than a safeguard control.

m3 — Verification agent gets no framing, so the note's own premise doesn't cover the final gate

SKILL.md:87-94

Line 24 leans on framing "required in step 2." The step-4 verification agent receives the diff constraint (:88) but no authorized-engagement framing, and runs on the same default model. Either apply the framing consistently or (preferably, with m2) drop the framing-as-mitigation claim.

m4 — No coverage-gap guard if an agent returns nothing

SKILL.md:93-94, SKILL.md:166

If any of the four analysis agents returns empty — refusal, error, or classifier decline — step 4 forbids the verification agent from introducing new findings and step 5 says to omit zero-finding sections entirely. The report then renders as a clean review with no indication that an entire analysis domain dropped out. This is worth fixing on any model.

Suggested addition to step 4/5: "If any analysis agent returns no findings and no ✅ Strengths, treat that domain as UNCOVERED and render a ⚠️ Coverage gap: <domain> agent returned no output line in the Summary. Do not report a clean review when an agent produced nothing."

---

⚪ Pre-existing (outside this PR's scope — noted, not blocking)

These predate PR #142 and would each need their own version bump. Two are cheap and high-impact enough to consider folding in.

1. allowed-tools is space-separated — SKILL.md:5. Every other skill and command in the repo uses commas, and allowed-tools is parsed as a comma-separated list — as written it reads as one malformed entry, so Read, Write, and Skill are likely not granted. The list also omits Task/Agent even though steps 2 and 4 launch five subagents. Repo convention is also Bash(gh pr diff:*) rather than Bash(gh pr diff *).
2. Bash(rm -f /tmp/security-review-*) scoping — SKILL.md:5. A trailing-wildcard rule matches on command prefix, so additional path arguments could be appended after the intended prefix. Tightening to a specific suffix (e.g. /tmp/security-review-*.diff) narrows the surface.
3. Rubric path won't resolve for subagents — SKILL.md:64,82. Bare relative references/security-review-rubric.md resolves against the reviewed repo's cwd, not the plugin. Three sibling skills in this plugin correctly use ${CLAUDE_PLUGIN_ROOT}/…. Agents that can't read the rubric improvise severity judgments — silently.
4. Cross-reference error — SKILL.md:91 says "applying the threshold matrix from step 2"; the matrix is applied in step 3 and defined in references/security-review-rubric.md. Terminology also drifts between "threshold matrix" and "triage matrix".
5. "approach this analysis without safety refusals" — SKILL.md:76. In a Bitwarden-maintained config file this reads as a refusal-suppression instruction. Asserting authorized scope without instructing the agent to suppress refusals achieves the same effect with better optics.

Separately, the repo's own scripts/validate-plugin-structure.sh globs agents/*/AGENT.md, while this plugin uses a flat agents/bitwarden-security-engineer.md — so this agent's frontmatter is never checked by that script in CI. Worth a follow-up to the script, not to this plugin.

---

Notes on this run

• ./scripts/validate-plugin-structure.sh and ./scripts/validate-marketplace.sh could not be executed in this environment (command approval denied). The equivalent checks — required files, plugin.json fields, frontmatter validity, changelog format, and four-way version consistency — were performed manually against the files and all pass.
• pnpm run lint (prettier + cspell) was not run here. New vocabulary introduced is "Fable" and "Mythos"; both are ordinary English words likely covered by the base dictionary, but a local pnpm run lint before merge is advisable since CI enforces it.

Recommendation

Approve with changes requested. Nothing here is a structural or security defect, and the repo's contribution process was followed correctly. Before merge, please address M1–M3 and m1–m2: either revert the default to model: opus and keep fable behind --model, or keep the Fable default and correct the three claims that the model documentation contradicts, plus document the data-retention prerequisite. m4 (coverage-gap guard) is worth adding regardless of which model wins.

[theMickster]

Thanks for proposing the change. I'm excited to see this in action 🚀

Out of curiosity, did you see anything in-particular that lead you to add this sentence @withinfocus (versus just a model name change)?

Note: Fable 5 carries built-in safeguards for high-risk domains (including cybersecurity) and falls back to Claude Opus 4.8 automatically when they trigger — the authorized-engagement framing required in step 2 keeps this defensive review on-task.

[withinfocus]

My counterintuitive stance on this is that given it's a Mythos-class model that it will provide a potentially-undocumented benefit on security-related tasks. Even when it does not and invokes this to-be-seen Opus fallback, it's no harm for us and we'd want that anyway. This stance could be totally wrong though.