[virtualsteve-exa]

Adds security/praxen/ — the "Praxen agent-behavior reports" the security README has been reserving a slot for — and documents a release gate alongside the existing red-team bar.

What this is

The red team asks "can an attacker who controls the telemetry make socxen misbehave?" — adversarial, runtime, and only over the paths it has fixtures for. Praxen asks "does the shipped code enforce what we say our policy is?" — static, whole-system, and it audits every rule in the remit, including controls no fixture has ever probed. The two are complementary; neither subsumes the other.

The gate

socxen does not ship a release with an open Praxen Critical finding. Fixed, or explicitly waived in writing by a maintainer with a rationale in the PR, before the tag. High / Medium / Low do not block — they're triaged into issues.

Documented gate, not a CI check — deliberately the same posture as the red-team release bar. A Praxen scan is an agentic analysis, not a deterministic test; it belongs in the checklist a human runs, not in a workflow that must go green on every push. CONTRIBUTING.md gains a Release gates section tabulating both.

Why Critical specifically: in Praxen's model a Critical is a control absent or defeated on the shipped default path, not a hardening opportunity. For an agent that reads attacker-influenceable telemetry and writes dispositions into a production SOC platform, that's the class that must not reach a tag.

0.6.9 result — the gate passes

Critical	0 — passes
Other	5 High · 7 Medium · 1 Low
Weighted RAISE	2.45 / 5 (Partial)
Remit coverage	50 rules — 31 verified · 18 partial · 1 gap
Independent audit	13 / 13 CONFIRMED, 0 unsupported, 0 remit defects

Categories: Limit Domain 2 · Balance KB 3 · Zero Trust 2 · Supply Chain 2 · Red Team 3 · Monitor 3.

Red Team scores 3 on the strength of the program already in this repo — the a10 arc in redteam/HISTORY.md (landed 3/3 → issue #30 → two prompt-level fixes measurably failed → architectural fix at the write sink → retest clean → promoted to a permanent regression fixture) is cited as a complete find→fix→verify loop. Monitor scores 3 for the default-on structured audit trail at the bridge's single chokepoint.

How the remit was written — and why that matters

Authored blind. The agent that wrote it read README.md, SECURITY.md and docs/** only — it was barred from skills/ and connector/. A remit written from the implementation describes what socxen does rather than what it should do, and a scan against it finds nothing.

It was then hardened over two rounds: a high-mode scan audit found 4 defective rules, an independent review found 5 more (including one introduced while fixing the first set), and a third check came back clean. All 8 Open Questions are resolved, each recording whether the docs settled it or a maintainer decided.

Please review the remit as policy, not as a report artifact — it's a claim about maintainer intent, and where the docs were silent (approver identity, volume caps, unattended operation, telemetry destinations) the answers recorded are the ones we inferred or chose. If any of them isn't what you intend, that's a remit fix, and it changes what future scans check.

Open items

Tracked as issues rather than folded in here: #71 (dependency pinning / lockfile / scanner) and #76 (red-team runner model alias + gate staleness). #72 (containment deny-list naming) was found by the previous scan and fixed in 0.6.9 — this re-scan verifies it: 68 rules, both spellings across both namespaces, invariant-tested in CI.

Verification

• 238 passed (uv run --with pytest ... pytest -q tests/)
• security/gen_aibom.py --check → AI BOM is current
• One test touched: the SPDX-header exemption for generated run records now covers security/praxen/results/ exactly as it already covered security/redteam/results/ — same rationale, same category of file. Authored docs under security/praxen/ carry the header.

---

🤖 Generated with Claude Code

[virtualsteve-exa]

Code-owner review, with independent verification. Verdict: READY once two small things are fixed — one is a public-repo hygiene item.

Verified independently ✅

• Suite + invariants: 238 passed / 0 skipped on the branch; gen_aibom.py --check current; CI green. The SPDX-test change is minimal and exactly parallel to the existing redteam/results exemption.
• Report internal consistency: JSON has 13 findings (5 High / 7 Medium / 1 Low, 0 Critical) matching the README table; 50 distinct R- rules referenced, matching the coverage claim.
• Spot-checked findings at their cited lines — accurate: 009 (run.py:341-342 floating --models sonnet default + the now-stale HISTORY.md:42 gate note) and 013 (all four uses: across the three workflows are mutable major tags) check out verbatim. The audit's sharpest catch on 001 also verifies: the snippet-merge instruction lives inside if [ "$CREDS_OK" = 0 ] (install.sh:445), so an install with credentials present never prints the merge instruction at all — that detail is worth carrying into whatever fixes #70/#73 land.
• No secrets/tenant data in the artifacts — all credential-shaped grep hits are rule text.

Fix before merge

1. Local absolute paths committed to a public repo. results/2026-08-12-socxen-0.6.9-audit.md:6-8 (×3) and one occurrence in the JSON embed /Users/steve.wilson/Documents/github/deckard/local/... — operator username plus an internal project name. The isolation claims survive with placeholders (<scan-workspace>/…); please scrub both files. The HTML is clean.
2. Dangling reference: SCAN_INSTRUCTIONS.md:52 points at CLONE_SHA.txt "beside this file," which is (rightly) not committed — it's scan-time state. Reword to "pin the SHA at scan time and record it in the results artifact" (the results do record 005fa4c).

Ask, non-blocking

3. Close the triage loop the gate itself promises. CONTRIBUTING now says non-blocking findings "are triaged into issues" — but 13 findings map to #71, #76, and the previously-fixed #72 only; the other ten have no recorded disposition. Suggest a short triage table (finding → issue / accepted-with-rationale / superseded) in praxen/README.md or beside the results. Note findings 001 and 012 land partly in #70/#73's lap — cross-reference rather than double-file.

For the maintainer (not this PR's author to resolve)

The remit's 8 Open Questions record five operator decisions (approver identity, case-write tier, no volume cap, no telemetry allowlist, missing-gate = warn-not-refuse). Those are policy, and maintainer sign-off on them is the substantive review of this PR — flagged to Steve directly.

Nice work overall: the blind-authoring discipline, the audit pass that re-reads every citation, and honest score rationale (band-edge calls recorded as such) make this the most defensible artifact in security/.

[virtualsteve-exa]

Thanks — all three addressed in 2f37c91. 238 passed, AI BOM current.

1. Local absolute paths — fixed, and thank you for catching it. That's a genuine hygiene miss on a public repo: operator username plus an internal project name, committed. Scrubbed all four occurrences (3 in the audit record, plus scan.workspace in the JSON) to <scan-workspace> / <socxen-checkout>. The isolation claims read identically with placeholders. Re-validated the JSON afterwards — 13 findings, 50 rules, weighted 2.45, unchanged. Swept the whole directory: no /Users/ and no operator name anywhere.

2. Dangling CLONE_SHA.txt — fixed. You're right that it's scan-time state and correctly uncommitted. Reworded to "pin the SHA at scan time and record it in the results artifact", and named the 005fa4c pin the committed run actually used, so the instruction is self-demonstrating.

3. Triage table — added, and you were right that the gate was writing a cheque the artifact didn't cash. All 13 findings now carry a disposition in security/praxen/README.md: #71 and #76 tracked, #72 marked previously-fixed-and-verified, 001/012 cross-referenced to #70/#73 rather than double-filed as you suggested. The remaining nine are marked awaiting triage with a note that disposition is the maintainer's call — I'd rather the table show an honest worklist than have a contributor invent dispositions for someone else's backlog.

I also carried your install.sh:445 catch into the table as a note for whoever fixes #70/#73 — the merge instruction sitting inside if [ "$CREDS_OK" = 0 ] means an install that already has credentials never prints it, so fixing the merge without fixing that branch would leave the most common upgrade path silent. That's a sharper observation than the finding itself made.

On the maintainer item: the remit's five operator decisions (approver identity, case-write tier, no volume cap, no telemetry allowlist, missing-gate = warn-not-refuse) were decided by @virtualsteve-exa during authoring, not inferred — each is recorded in the Open Questions section with the date. Worth an explicit confirm on merge, since they're the substantive policy content and they set what every future scan checks.

[virtualsteve-exa]

Re-reviewed 2f37c91 — all three items verified fixed: swept both artifacts for /Users/ and the project name (0 hits), the SHA-pinning note now records 005fa4c in prose with no dangling file reference, and the triage table is exactly what the gate needed — honest awaiting-triage rows beat silently unfiled findings. Review items are clear from my side; remaining before merge is maintainer sign-off on the remit's five operator decisions (flagged to Steve) and Matt's requested review.