/wbSecure — Exhaustive Simulation ()

/wbSecure is the red team. It wears the opposite hat from /wbAudit: where /wbAudit --profile="security" is a defensive scan ("are there known vulnerabilities here?"), /wbSecure is offensive ("how would I attack this?"). The two complement each other; both produce reports, neither writes plan cells.

Read this if you want to know what makes /wbSecure different from /wbAudit's security profile, why --force-past-security is a name that signals destructive intent, and where security review ends and the security work begins.

---

1. Role & target

Aspect	Behavior
Role	The Red Team — adversarial security review from an attacker's perspective.
Target	A file, directory, glob, or sub-system focus.
Cell scope	None directly. Output is a security report + optional follow-up plan rows via chaining (not via direct mutation).
Side effects allowed	Reading code, reading dependency manifests, reading auth flows, simulating attack paths in prose.
Side effects forbidden	Editing source code, running actual exploit attempts, fetching CVE databases (no external calls), modifying secrets/env files.

The "opposite hat" framing is the design center. /wbAudit --profile="security" looks for known patterns of vulnerability — they're checklist items: "is eval used? is innerHTML used? are tokens in localStorage?" /wbSecure instead asks "as an attacker, what would I try?" The output is reasoning chains: "I'd start with the auth flow, look for X, escalate via Y."

The two are valuable together. A defensive checklist might miss a vulnerability that's specific to this code's logic; an offensive scenario might miss a generic pattern that's everywhere. Run both for high-stakes code (auth, payments, tier enforcement).

---

2. Argument resolution matrix

Form	Example	What /wbSecure does
File	Command: /wbSecure core2/packages/wb-core/src/tierEnforcement.js	Deep adversarial review of one file; threat-models its inputs and call paths.
Directory	Command: /wbSecure core2/packages/wb-core/src/auth/	Walks the auth-relevant code; produces attack scenarios per entry point.
Glob	Command: /wbSecure "core2/packages/*/src/**/auth*.{js,ts}"	Cross-package; expensive; warns about scope.
Free-text scope	Command: /wbSecure "the JWT handshake"	Resolves keyword across workspace; refuses if ambiguous.
--focus="<topic>"	Command: /wbSecure --focus="payment flow"	Same as free-text but explicit.

---

3. Flag matrix

/wbSecure has two flags. Both shape what's in scope, not how the review behaves.

Flag	Shortcut	Purpose
--focus="<topic>"	-f	Scopes the review to one sub-system (auth, tier-enforcement, payment, data export).
--force-past-security	-F	Override flag. Tells /wbSecure to proceed even when the agent would otherwise refuse (e.g., reviewing code with known sensitive secrets visible, or reviewing in a context where the report would be immediately consumable by an attacker). Capitalized to signal destructive intent.

What --force-past-security actually unblocks

The flag exists for a narrow set of cases the agent would otherwise refuse:

Refusal	What -F overrides
File contains literal secrets in source	Agent normally refuses to include the file in the report. -F allows inclusion.
Review target is a third-party dependency	Agent normally refuses (third-party security is upstream's responsibility). -F lets you proceed for a vendored/forked dep you need to review.
Adversarial output would be high-detail attack steps	Agent normally produces high-level threat models. -F allows step-by-step attack chains (only for code you control).

The flag's name is uncomfortable on purpose. "force" + "past security" reads as a warning — using it should require a moment of "am I sure?"

---

4. Pipelines (the agent-native scenarios)

📋/wbSecure Exhaustive Simulation

Adversarial review of tier enforcement/wbSecure core2/packages/wb-core/src/tierEnforcement.js

> /wbSecure core2/packages/wb-core/src/tierEnforcement.js

[SYSTEM] Target: tierEnforcement.js

[MODE] Adversarial — assume attacker wants to bypass tier checks.

[SCAN] Reading file (87 lines, exports enforceTier)...

[CONTEXT] Reading callers via grep: 6 call sites across wb-core.

## Threat model

The file's job is "given a JWT and a requested action, decide whether

the caller's tier permits it." An attacker's goals would be:

1. Escalate from Free → Paid tier without paying.

2. Bypass the check entirely (tier='admin' regardless of JWT).

3. Replay a Paid-tier token after subscription expiry.

## Attack paths considered

### Path 1 — Algorithm confusion (`alg:"none"`)

**Severity:** High

**File:** tierEnforcement.js:42

**Attack:** Craft a JWT with header `{"alg":"none"}` and tier="admin"

in payload. If the verify function accepts `alg:"none"`, no signature

is required.

**Status in current code:** The verify code does NOT include an

algorithm denylist. `jwt.verify()` is called without `algorithms: ['HS256']`

constraint.

**Verdict:** **Vulnerable.** This is the same finding that came up

in /wbAudit security profile — both lenses surface it because it's

both a known-pattern issue and an obvious attack path.

### Path 2 — Tier confusion via JSON injection

**Severity:** Low

**Attack:** If tier is parsed from a string field that allows

escape sequences, an attacker might inject control characters that

fool downstream string compares.

**Status in current code:** Tier is read from `decoded.tier` (a JS

object property), not from a raw string. No injection surface.

**Verdict:** Not exploitable as written.

### Path 3 — Replay after expiry

**Severity:** Medium

**Attack:** A token signed correctly today is valid until its `exp`

claim. If the user downgrades tomorrow, the token's tier is still

the old one until expiry.

**Status in current code:** No revocation list. Standard JWT

behavior — tokens are valid until `exp`.

**Verdict:** Acceptable for small `exp` windows (≤1 hour). For

longer-lived tokens, add a revocation check or use server-side sessions.

## Recommendations

1. **Path 1 fix:** Add `algorithms: ['HS256']` to the verify call.

This is also a /wbAudit P0 finding.

2. **Path 3 evaluation:** Confirm the deployed `exp` window. If >1h,

plan the revocation work; if ≤1h, document the trade-off.

[NO MUTATION] Report only. To track findings as plan rows:

/wbSecure ... --wbPlan (chains through /wbActOn).

💠 Pipeline Adversarial review of tier enforcement

💠 Pipeline The --force-past-security override

A user wants to review a vendored dependency they've forked into the workspace:

💠 Pipeline Cross-cutting focus (--focus="auth")

---

5. Edge cases & refusals

Trigger	What /wbSecure does
No target	Halt.
Target contains literal secrets in source	Refuse without -F.
Target is a third-party (node_modules/, vendor/)	Refuse without -F.
Free-text target with 3+ unrelated matches	Halt with disambiguation. Adversarial review is bias-amplifying when fuzzy-matched.
--focus=""	Halt — empty focus.
Cross-package review with no relevant code found	Honest "no auth-related code in target." Suggests narrowing.
Review request that would produce step-by-step attack instructions	Default: high-level only. -F permits step-by-step (for code the user owns).
Memory contradicts the framing (e.g., user asks about a feature memory says was removed)	Surface the contradiction; ask whether the user wants a historical or current review.

The pattern: /wbSecure is the offensive lens — adversarial reasoning, not pattern-matching. It complements /wbAudit --profile="security" by surfacing code-specific attack paths the checklist might miss. The -F override is named to signal destructive intent and is recorded in every report it produces. The output is reasoning the user can follow and verify; /wbSecure doesn't fix things, doesn't generate exploit code, and doesn't fetch external CVE data — it stays inside the workspace and the user's threat model.