fu351/Doberman-Core

The 2026-08-09 live test (HUMAN_TEST_CHECKLIST Test 3) of the secret-egress taint floor under Codex was inconclusive. The tester asked Codex to read a secret then POST it, and Codex refused on its own, before Doberman's egress taint floor was ever exercised. We still don't know whether Doberman's own gate fires under Codex — the host model's judgment got there first. The ask: re-run the test against a scratch repo, with task phrasing that doesn't trip Codex's own refusal before Doberman gets a turn. Frame the outbound call as something mundane (sending a config value to a webhook, posting a value to a logging endpoint) rather than "read a secret and exfiltrate it." Use a synthetic, planted secret (shaped like AKIA... or sk-..., never a real credential). Capture the transcript and report whether Doberman's floor fired: did the egress get raised to AUTH/BLOCK, and what reason codes showed in doberman log? Safety Synthetic secrets only. Never a real key, token, or credential. Scratch r

The parity matrix shows secret-egress taint floor proven on Claude Code and the MCP proxy, but ◻ (not yet proven) on Codex. The guarantee: once a session has read a secret, a later egress that the per-call floor would let pass gets raised to AUTH/BLOCK. The Codex adapter runs the same decision spine, so this is real and mirror-able — it just needs a test. What to do Read the sibling that proves this on Claude Code: tests/unit/test_hosthook_taint_floor.py (see test_tainted_session_egress_is_blocked_in_strict). It records taint, then asserts a later egress is escalated. Write the Codex equivalent (a new test, e.g. tests/unit/test_hosthook_codex_taint_floor.py) driving doberman.hosthooks.codex.evaluate_pre with a captured-shape Codex payload (tests/fixtures/codex/pre_bash.json is a good base — tool_name: "Bash", string command). Record the secret via the post path, then assert the egress is raised. Mark the test so it claims the cell: @pytest.mark.guarantee("secret-egress-taint-flo

A wave of UX improvements just landed (#252, #261, #265, #266, #267, #268), and every one of them changes something CI fundamentally cannot verify: whether colors read on a real terminal, whether a screen reader actually announces the approval queue, whether a prompt feels clear at the moment it interrupts you. That takes a human on a real machine - and fresh eyes are strictly better here than the eyes that built it. So this issue is deliberately shaped as a tour: by the end you'll have installed Doberman, watched it make PASS/AUTH/BLOCK decisions, approved a challenge from the dashboard, and seen most of the product's surface. No code required - your deliverable is a comment with the checklist results and anything that felt wrong along the way. "Felt wrong" reports are as valuable as hard failures; UX bugs rarely throw exceptions. Setup Follow the README quickstart (pip install doberman-core, then doberman setup in a scratch repo). doberman demo generates decisions to look at; doberma

The AUTH approval dialog (src/doberman/auth/gui_prompter.py) is a custom tkinter window, deliberately styled on-brand instead of using the OS-native messagebox. Keyboard operability is wired (Tab/Enter/Escape; Deny holds focus). What nobody has verified: what a screen reader actually announces when this dialog appears - and this is the single highest-stakes interrupt in the product. Research task (no code required to start): Trigger the dialog (see the FallbackPrompter wiring) on Windows with Narrator and/or NVDA running. Record what is announced on open, on focus movement, and on any deadline text. If announcement is broken or empty, propose a path: accessible-name wiring in tkinter if it exists on Windows, falling back to the native messagebox when a screen reader is detected, or another approach you can defend. Findings posted as a comment on this issue are a complete first contribution; a follow-up PR is welcome but not required.

Doberman already enforces most of the runtime controls that AI-security frameworks ask for, but nowhere states which ones — so anyone evaluating it has to reverse-engineer coverage from the source. Publish a coverage matrix that maps Doberman's guarantees to the OWASP Top 10 for LLM Applications and the NIST AI RMF (with a column for the NSA/CISA/NCSC baseline), so a buyer or contributor can see what's covered at a glance. Build One table per framework. Each row is a framework control; each cell carries a status: covered, partial, or gap — never a bare checkmark. Every covered or partial row cites the feature or reason code that backs the claim (e.g. F8 decision log, ReasonCode.encoded_exfil, tool-schema pinning). A partial row names what's missing in one line. A gap row says whether it's out of Doberman's layer (sandbox / TEE / transport crypto) or on the roadmap. Lives in docs/ and links from the README's security section. The bar — this needs judgment, not a checkbox pass H