controlzero 1.13.7__tar.gz → 1.13.9__tar.gz

{controlzero-1.13.7 → controlzero-1.13.9}/CHANGELOG.md

@@ -1,5 +1,401 @@
 # Changelog
 
+## 1.13.9 (2026-07-28): Kiro IDE hooks execute on 1.0.x and stay in the correct project
+
+### Fixed
+
+- **Kiro IDE hooks no longer appear enabled while silently executing on
+  nothing on Kiro 1.0.x (#1952).** The installer now emits `preToolUse` and
+  `promptSubmit` hooks in the `.json` format read by Kiro's 1.0 hook loader,
+  while retaining the legacy hook files needed by older builds. It does not
+  dual-emit `fileEdited`, because both loaders can execute that event and
+  doing so would duplicate scans and audit rows. `promptSubmit` now actually
+  runs on current Kiro; `preToolUse` is installed in the working format but
+  remains disabled by its existing opt-in flag.
+- **Kiro payloads can no longer be claimed by the Claude Code adapter and
+  evaluated under the wrong project and DLP profile (#1945).** Kiro IDE 1.0+
+  and Kiro CLI v3 use PascalCase agent-harness events that overlap with Claude
+  Code. Kiro-specific payload signals now win routing, so attribution, API-key
+  selection, policy, and DLP configuration stay with the Kiro integration
+  instead of silently crossing tenants.
+- **An inherited `CONTROLZERO_CLIENT` can no longer redirect a Kiro IDE call
+  into another host's configuration (#1951).** The Kiro shim now pins its
+  client identity rather than preserving a value inherited from the launching
+  environment, preventing the same silent wrong-project and wrong-DLP-profile
+  outcome.
+- **A DLP mask match on a host that cannot rewrite tool input now tells the
+  agent what to fix (#1946).** The denial identifies the affected argument and
+  detector type without echoing the sensitive value, so the agent can retry
+  with the secret removed instead of dead-ending on a generic unsupported-mask
+  message.
+
+### Added
+
+- **`controlzero coverage` is generated from the adapters' declared
+  capabilities (#1947).** The CLI now exposes each host's enforcement tier,
+  deciding and observation events, argument delivery, rewrite support, and
+  known gaps from the same data used by adapter contracts.
+
+### Kiro IDE enforcement status
+
+Kiro IDE remains `tier=observe`; this release does **not** claim deterministic
+enforcement. It makes the enabled `promptSubmit` hook execute on Kiro 1.0.x and
+puts `preToolUse` one enable flag away from execution. Until that flag is
+enabled and the deterministic block path is verified end to end, the SDK's
+coverage declaration intentionally remains observe-only.
+
+## 1.13.8 (2026-07-27): warn decisions reach the agent + Kiro IDE adapter unblocked (P0)
+
+### Added
+
+- **Branch-aware `git` actions and cloud-CLI subcommand actions (#1734, #1751).**
+  The #437 semantic-class layer classified a shell command's danger class but
+  never exposed its operand, so `git push origin main` and
+  `git push origin feature/x` both collapsed to `Bash:git` -- a policy could not
+  allow feature-branch pushes while denying a push to a protected branch. A
+  `Bash` call now additionally promotes `git <sub> ... <ref>` into a matchable
+  `git_<sub>:<target>` action (no ref named on the line -> `git_<sub>:*`) and
+  `aws` / `gcloud` / `kubectl` into `<cli>:<sub>`, so a rule can
+  `deny git_push:main`, `deny git_push:release/*` or `deny aws:s3` and let
+  everything else fall through to `default_action`. Refspecs reduce to their
+  destination (`src:dst` -> `dst`, a leading `+` stripped), `checkout -b` /
+  `switch -c NAME` resolve to the new branch name, and `git -C <dir>` /
+  `-c <name=value>` global options are skipped. The per-command `Bash:git`
+  action is still emitted, so existing `Bash:*` rules are unaffected.
+  Byte-identical to the Node and Go SDKs (`git_command_cases` and
+  `cloud_subcommand_cases` in `parity-cases.json`).
+  **Upgrade impact:** these are NEW candidate actions evaluated on every `Bash`
+  call. A policy that already carries a rule in the `git_*`, `aws:`, `gcloud:`
+  or `kubectl:` namespace will now match shell commands it never matched
+  before -- audit those rules before upgrading.
+  **Authoring note:** use explicit branch names or a namespace glob
+  (`release/*`). A bare `git_push:*` as an "any nested branch" matcher is not
+  portable: Python `fnmatch`, Node `minimatch` and Go `path.Match` disagree on
+  whether `*` crosses `/`.
+
+### Fixed
+
+- **DLP never scanned a `warn` decision, so a `warn` catch-all silently
+  disabled data-leak scanning for an org's whole shell surface (#1927, P0).**
+  The scan gate in `_internal/enforcer.py` read
+  `if decision.allowed and args and self._dlp_scanner is not None:`.
+  `.allowed` is `effect == "allow"`; a `warn` is neither `.allowed` nor
+  `.denied`, so a warn-matched call proceeded to the tool with its arguments
+  NEVER scanned. Our own shipped "Shell Command Restrictions" template carried
+  an unconditional `warn bash:*` catch-all, so every shell call in an org using
+  it was exempt -- reported by a customer as "DLP isn't working". The
+  half-canonical `audit` policy effect is now rejected explicitly instead of
+  falling through differently across SDK and backend consumers. The gate is now a positive
+  membership test against `DLP_SCANNED_EFFECTS`, derived as
+  `ALL_EFFECTS - {"deny"}`, so every effect whose call PROCEEDS is scanned and
+  any effect added in future is scanned by default rather than silently
+  exempted.
+- **The no-match default was structurally unreachable from the DLP scan
+  (#1931, P0).** That same gate sat INSIDE the per-rule loop, two lines before
+  its `return decision`. `evaluate()`'s no-match fallthrough returns from
+  outside the loop, so `default_action: allow` and `default_action: warn` --
+  the steady state for every allow-by-default org, on every call that matches
+  no rule -- were never scanned at all. Both decision origins now route
+  through a single chokepoint, `PolicyEvaluator.finalize_decision`, which is
+  the only caller of the scan.
+- **An empty findings list meant both "scanned, clean" and "never scanned"
+  (#1927).** That ambiguity is why the bypass went unnoticed in the audit
+  trail for as long as it did. Every `PolicyDecision` and every row written to
+  the local audit log (`~/.controlzero/audit.log`) now carries required,
+  structured `dlp_outcome`, always with a non-empty reason. A `PolicyDecision`
+  cannot be constructed without it. The compatibility `dlp_status` projection
+  carries the same closed status and never defaults a missing value to clean.
+
+  The vocabulary is **one member, one meaning**:
+
+  | Status | Means |
+  | --- | --- |
+  | `clean` / `findings` | The scanner ran and returned a terminal verdict |
+  | `skipped` | Policy denied (nothing executes) or the data is explicitly ineligible |
+  | `unavailable` | The scanner could not be used. **Never** means clean |
+  | `mask_unsupported_on_host` | A mask matched on a host that cannot rewrite arguments |
+  | `suppressed` | **An admin deliberately turned enforcement off. Nothing else.** |
+  | `not_finalized` | Internal pre-finalization sentinel |
+  | `not_applicable` | The tool already ran (post-execution observation) |
+  | `unreachable` | An origin that structurally cannot reach the chokepoint |
+
+  An earlier draft of this fix routed six unrelated plumbing states through
+  `suppressed`. That would have rebuilt the very defect being fixed one field
+  over: `#1927` was an empty findings list meaning both "clean" and "never
+  looked", and a single `suppressed` would have meant both "an admin chose this"
+  and "the code did not get there" -- so an operator asking *show me everything
+  DLP did not block* could not separate deliberate policy from plumbing.
+  Disambiguating by also reading the free-text `reason` was rejected: `reason`
+  has no completeness guard and cannot carry a safety-critical distinction.
+
+  `suppressed` therefore has **no producer in this release** -- the explicit
+  admin observe posture is not implemented yet (#1939) and the default is
+  ENFORCE. The member is reserved so no plumbing state can claim the name
+  later. A critical telemetry alarm fires if the `not_finalized` sentinel
+  reaches an execution boundary, and both the idempotence guard and the
+  outcome-stamping check key on the status MEMBER, never on the reason string.
+- **`guard_with_approval(retry_guard=False)` returned an allow that was
+  neither DLP-scanned nor audited (#1927).** On that path a human-approved
+  call proceeded with its ORIGINAL arguments and left no audit row. It now
+  routes through the same chokepoint and writes an audit row. A human
+  approving a tool call does not approve exfiltrating a secret in its
+  arguments.
+- **The Node SDK is at parity, not tracking behind (#1937).**
+  `@controlzero/sdk` carried BOTH of the same bypasses -- `enforcer.ts` gated
+  the scan on `decision.allowed` inside the matched-rule branch -- so a `warn`
+  catch-all disabled DLP there exactly as it did in Python. Node now has the
+  same single chokepoint, the same subtraction-derived scanned-effect set, and
+  the same closed outcome vocabulary. Both suites assert against ONE shared
+  contract fixture (`tests/parity/dlp_control_outcomes.json`), so adding a
+  status or an effect to one SDK alone turns the other SDK's suite red. Nothing
+  structural previously stopped one from being fixed while the other was left
+  behind, which is how this shipped in two SDKs at once. **The Go SDK is NOT
+  ported and still carries the bypass** -- #1937 stays open for it.
+- **A human-approved HITL request stays an `allow` (#1936).** An in-flight
+  revision of this work flipped the synthetic approve decision to a `deny` so an
+  unscanned allow could not escape. That produced the incoherent pair
+  `status == "approved"` with `decision.denied == True`, breaking every caller
+  reading `approval.decision.allowed`. The DLP concern belongs in the outcome,
+  not the effect: no scanner or arguments exist at that point, so the decision
+  records `unreachable(hitl_approval_requires_reguard)` -- which can never read
+  as "scanned, clean" -- and the `Client` re-guards the original request through
+  the chokepoint before anything executes.
+
+- **The Kiro IDE preToolUse hook blocked every tool call because of OUR
+  adapter, not an upstream bug (#1885).** Verified against the shipped build on
+  the reporting machine -- Kiro IDE **0.12.333** (commit `c7e35289`, built
+  2026-06-10, read from `Kiro.app/Contents/Resources/app/product.json`): the IDE
+  does NOT deliver `USER_PROMPT={}`. Its v1 hook provider sends
+  `USER_PROMPT=JSON.stringify(toolArgs)` -- the tool ARGUMENTS with **no tool
+  name** (postToolUse sends the full `{toolName, toolArgs, toolResult,
+  toolSuccess}`). `kiro_adapter._normalize` REQUIRED `toolName`, returned
+  `None` for that shape, and every real IDE tool call landed on the
+  unknown-payload fail-closed path. An args-only payload is now evaluated on
+  the arguments that did arrive, under the explicit placeholder tool
+  `kiro_ide_unknown_tool`, and MARKED (`cz_payload_degraded`) plus a loud
+  stderr line so a tool-identity-unknown decision can never be read as a normal
+  argument-level governed decision. A genuinely empty payload (`{}`, non-JSON,
+  a JSON non-object) still fails closed.
+- **Adapter exit codes are now safe across the Kiro 1.0 boundary (#1885).**
+  Kiro 1.0 redefines a non-zero exit OTHER than 2 as a warning that lets the
+  tool PROCEED. The adapter now emits ONLY 0 or 2: an uncaught exception is
+  caught at the top level and collapsed to the block code instead of escaping
+  as Python's exit 1 (which blocks on 0.12.x and would silently allow on
+  1.0.x). `controlzero install kiro` and `controlzero kiro verify` print the
+  version boundary, the detected Kiro build, and the residual risk.
+- **Forward-compatible with the v2 hook provider (#1885).** The same 0.12.333
+  bundle carries a second provider (session setting `hooks.v2 === true`) that
+  spawns hooks with an EMPTY env and delivers a Claude-Code-shaped JSON payload
+  on STDIN. The adapter now falls back to a timeout-bounded stdin read when
+  `USER_PROMPT` is empty, so a flip to v2 yields full-fidelity governance
+  instead of fail-closed-on-everything. The v1 path never touches stdin.
+
+- **A `warn` decision is no longer byte-identical to an allow on the hook
+  surface (#1903, P0).** `controlzero hook-check` had no warn branch: on the
+  enforcer's `PolicyDecision` a `warn` effect satisfies neither `.denied` nor
+  `.allowed`, and the CLI's only decision branch was `if decision.denied:`. A
+  warn therefore fell through to the allow tail and was re-emitted as
+  `{"decision":"allow","reason":"[Control Zero] Allowed: <tool>"}` -- the
+  operator's warn message was discarded on every host. In the reported
+  incident a `find <dir> -mindepth 1 -delete` was classified CORRECTLY as
+  semantic class `file_delete` with a matching `warn` rule, and the agent was
+  handed an unqualified allow; the warn was visible in the dashboard only.
+  A warn still PROCEEDS (unchanged advisory contract, exit 0, no host block or
+  prompt token on any surface), but the operator's reason now reaches the
+  agent and the human, branded `[Control Zero] WARN: <reason>` on stdout and
+  stderr. Claude Code and Codex CLI additionally use the documented
+  non-deciding channels `systemMessage` (human) and
+  `hookSpecificOutput.additionalContext` (model) -- never `permissionDecision`,
+  which would auto-approve and bypass the user's own permission prompts.
+  Antigravity keeps its documented `decision:"allow"` token and carries the
+  warn text as the reason. Cursor IDE/CLI, which drop `reason` entirely on the
+  proceed path, now carry it in `user_message` / `agent_message`.
+
+- **E1404 (TLS verification failed) pointed at a knob the SDK never reads
+  (#1824).** The fix hint told users to set `REQUESTS_CA_BUNDLE`, which appears
+  nowhere in the SDK's TLS path, so anyone hitting a TLS failure against an
+  air-gapped or self-hosted backend followed it and stayed broken. The bundled
+  `error_codes.yaml` now names the real custom-CA surface --
+  `CONTROLZERO_TLS_CA_BUNDLE`, `tls_ca_bundle` in `~/.controlzero/config.yaml`,
+  or `controlzero setup --tls-ca-bundle` -- and leads with the private-CA /
+  self-signed certificate case (the common cause), keeping clock skew as the
+  fallback. This text is spliced into `str(exc)` for every E1404, so it is what
+  the user sees on CLI stderr and in logs.
+
+### Changed
+
+- **A DLP `block` match now DENIES a `warn` decision, and a DLP
+  `mask` match now applies to it (#1927) -- READ THIS BEFORE UPGRADING.**
+  Now that proceeding decisions are actually scanned, the scan's verdict
+  applies to them. A `warn` rule promises that THE RULE will not block; it
+  does not exempt the call from a mandatory org-level data control, and the
+  alternative -- letting any `warn` rule silently downgrade the org's DLP
+  posture -- is precisely the bypass being fixed.
+  **Upgrade impact, stated plainly:** an organisation running a `warn`
+  catch-all (including the `warn bash:*` in our own shipped "Shell Command
+  Restrictions" template, and any observation-only deployment) will start
+  seeing DENIES it has never seen before. Those calls were always violating a
+  DLP `block` rule; the SDK was not looking. The same is true for
+  `default_action: allow` / `warn` on calls that match no rule. On the
+  coding-agent hook surface the change is wider still: `hook-check` escalates
+  ANY decision carrying `masked_args` to a block (no host hook protocol can
+  hand rewritten tool input back), so a `warn` or a no-match-default call with
+  a MASK hit -- which previously could not happen -- will now block on Claude
+  Code, Gemini CLI, Codex CLI, Kiro and Antigravity. Before upgrading, review
+  your DLP rules with `action: block` and `action: mask` against the traffic
+  your `warn` rules cover.
+- **DLP masking is negotiated before the verdict, never corrected after audit
+  (#1927, #1938).** Masking rewrites the
+  arguments the agent receives. With warn/no-match-default now in scope,
+  it can do so on a path where the operator only asked to be WARNED, so a
+  masked decision carries an explicit `dlp_masked` flag and the audit row
+  records `dlp_masked: true`.
+
+  Mask capability is now **per host, declared as data** on each adapter's
+  coverage record (`can_rewrite_tool_input`, `rewrite_field`,
+  `rewrite_events`), verified against each vendor's own documentation. A
+  previous draft of this entry stated that the hook protocol of *every* host
+  "cannot return rewritten tool arguments". **That was wrong**, and correcting
+  it is why this paragraph exists (#202 no-false-claims):
+
+  | Host | Can rewrite tool input | Masking behaviour in that release |
+  | --- | --- | --- |
+  | Claude Code | Yes -- `hookSpecificOutput.updatedInput` | **Masks and proceeds** |
+  | Gemini CLI | Yes -- `hookSpecificOutput.tool_input` (BeforeTool) | **Masks and proceeds** |
+  | Codex CLI | Yes, but only alongside `permissionDecision:"allow"` | Denies (see below) |
+  | Cursor IDE | Yes, on `preToolUse` only -- `updated_input` | Denies (see below) |
+  | Cursor CLI | No (only `beforeShellExecution` is wired) | Denies |
+  | Kiro CLI / IDE | No (exit-code-only contract) | Denies |
+  | Antigravity | No (`decision`/`reason`/`permissionOverrides` only) | Denies |
+  | Unknown host | Unknown, so treated as No | Denies |
+
+  **What changed for you:** on Claude Code and Gemini CLI a DLP `mask` match no
+  longer blocks the call -- the redacted arguments are sent to the host and the
+  call proceeds. Previously it was a hard deny on every host.
+
+  **Two capable hosts are deliberately NOT enabled**, and this is a named gap
+  rather than an oversight (#1938). Codex CLI's documented rewrite is only valid
+  with `permissionDecision:"allow"`, which would auto-approve the call and
+  bypass Codex's own confirmation -- trading a fail-closed deny for a fail-open
+  auto-approve is a separate security decision, not a side effect of a
+  scan-coverage fix. Cursor IDE's rewrite has not been observed taking effect on
+  a live host, and Cursor staff report `allow`/`ask` are currently ignored
+  there; enabling a mask we have not seen applied is the one DLP failure mode
+  with no recovery (we report a mask, the raw secret runs). Both stay at
+  today's behaviour: the mask escalates to a deny recorded as
+  `mask_unsupported_on_host(host_cannot_rewrite_arguments)`, decided BEFORE
+  audit and host rendering, so the audit row and the wire verdict agree.
+
+  Antigravity has an undocumented `overwrite` field in its Go runtime. It is
+  **not used and must not be**: it is reported broken (the permission review
+  fires on the ORIGINAL call and the overwrite is silently discarded), which
+  would mean believing we masked while the raw secret executed.
+- `controlzero kiro verify` now reports **per-workspace Kiro IDE hook
+  coverage** and names the workspace path it inspected. Verify previously
+  reported PASS while the user's actual IDE workspace was ungoverned, because
+  IDE hooks are per-workspace and had been installed elsewhere. The CLI
+  PASS/FAIL verdict is unchanged and now says explicitly that it covers the
+  Kiro CLI surface only. New `--workspace` option (defaults to the current
+  directory).
+- The IDE Pre Tool Use hook template still ships **disabled** (unchanged), but
+  its description no longer repeats the false "empty payload" claim. It now
+  states the verified build, the real payload shape, and the two real limits:
+  tool-NAME rules cannot match a v1 preToolUse call, and on the v1 provider the
+  block is LLM-mediated (any hook output intercepts the call and the model is
+  told the tool did not run, then decides) rather than a deterministic stop.
+
+- **The Kiro IDE adapter now BLOCKS a deciding event whose DLP scan coverage
+  cannot be established (#1892) -- new behaviour on a hook that ships ENABLED.**
+  Where the adapter cannot prove the scanner will see the whole payload, it
+  exits 2 instead of forwarding an unvouched-for scan dressed up as a governed
+  decision. Triggers are policy-independent: a raw payload over 1,000,000
+  characters, decodable JSON still nested past depth 3, or any exception raised
+  while decoding. This reaches `preToolUse` AND `promptSubmit`, and
+  `ide-prompt-submit.kiro.hook` ships `"enabled": true` -- in 1.13.7 the
+  promptSubmit branch had no coverage concept and could not block at all. File
+  events (`fileSave`) are post-write and observe-only, so they proceed loudly
+  rather than pretending they were scanned. There is currently NO opt-out for
+  this path: `CZ_KIRO_UNKNOWN_PAYLOAD=open` is consulted only on the earlier
+  empty/unparseable-payload branch and does not cover it (tracked in #1925). If
+  you hit this on a legitimate payload, capture its SIZE and SHAPE (never its
+  content) and report against #1892.
+- **The Kiro IDE adapter's DLP scan surface is wider, so previously-allowed
+  input can now DENY (#1892).** Every normalised payload now carries the full
+  received payload on `tool_input` -- every JSON key, duplicate members,
+  resolved `\uXXXX` escapes and one further decoded JSON layer, or the raw bytes
+  when it is not JSON. `hook-check` scans the recursively extracted string
+  values of `tool_input`, so a prompt or tool argument containing a JSON blob
+  whose KEY names or escaped content match a DLP block rule now denies where
+  1.13.7 allowed. Known side effect: DLP findings for tool events can appear
+  twice in a single audit row, which changes finding counts for existing
+  customers.
+
+### Known gap
+
+- The **Node** SDK adapter (`sdks/node/controlzero/src/cli/kiroAdapter.ts`)
+  still returns `null` when `toolName` is absent and therefore still blocks
+  every call if its IDE preToolUse hook is enabled. Its template description
+  now says so. The port of this fix is tracked in #1885.
+
+- The **Node** SDK has no `warn` branch at all:
+  `sdks/node/controlzero/src/cli/main.ts` still branches only on
+  `decision.denied`, and no Node host adapter carries warn text on a proceed
+  path. The #1903 fix above is **Python-SDK only** -- for a `@controlzero/sdk`
+  user a `warn` is still discarded and re-emitted as a bare allow on every host
+  named there. The port is tracked in #1923.
+- **DLP residuals from this release, named rather than left silent.** None of
+  these is a regression; each is a boundary this fix did not reach:
+  - **Three decision origins still proceed without reaching the DLP chokepoint
+    (#1936):** the CLI's pre-`Client` bundle-missing allow, the HITL approver
+    approval, and the no-policy pass-through allow. All three now RECORD
+    `unreachable` with a specific reason instead of producing a row that reads
+    like a clean scan, so they are visible in the audit trail -- but the scan
+    genuinely does not run there.
+  - **`dlp_findings` and `dlp_status` never leave the machine (#1935).**
+    `audit_remote._build_wire_entry` carries neither field, so the remote sink
+    and the dashboard do not see this signal. Everything this release says about
+    the audit trail is true of the LOCAL log (`~/.controlzero/audit.log`) and the
+    decision object; it is NOT yet true of the wire. Closing it needs matching
+    backend `AuditIngestEntry` columns.
+  - **The explicit admin observe posture is not implemented (#1939).** `suppressed`
+    is reserved and producerless; the only posture available today is ENFORCE.
+    An org that genuinely wants detect-only cannot yet elect it.
+  - **Codex CLI and Cursor IDE can rewrite tool input but are not enabled
+    (#1938)** -- see the masking entry above for why each was held back.
+  - **The Go SDK still carries both bypasses (#1937).** Only Python and Node are
+    fixed in this release.
+  - **Three origins write NO audit row at all (#1941)** -- broader than the DLP
+    gap above, and worth stating plainly: the no-policy pass-through allow, the
+    synthetic HITL grant deny (7 call sites, whose docstring claims it records
+    to the audit store while the body only logs a warning), and the CLI's
+    unenrolled first-run allow, which exits before a `Client` exists. Making
+    every decision carry a truthful `dlp_outcome` is worth nothing on a path
+    that never persists one.
+
+### Fixed (audit fidelity)
+
+- **The observing posture survives a DLP override.** `observe` was set only on
+  the matched-rule construction, so every DERIVED decision -- the DLP block
+  override, the mask-boundary fail-closed deny, the size-cap deny and the
+  scanner-unavailable deny -- silently dropped it. A DLP-block deny made under
+  an observe posture was indistinguishable from an enforcing deny in the audit
+  row. Fixed in both SDKs.
+- `controlzero validate` still warns on CUSTOM-VOCABULARY actions the backend
+  accepts -- `trade.execute`, `patient.read`, `data.read`, `mcp.tool.call`,
+  `production:*` -- so four shipped dashboard templates print `rule action
+  '<x>' is not a known canonical action or alias` and then parse and enforce
+  correctly. The warning is cosmetic (no decision depends on it) and is tracked
+  in #1918. The semantic-class namespaces are NO LONGER affected: #1913
+  registered `file_delete`, `network`, `git_<sub>` and `aws`/`gcloud`/`kubectl`
+  in all three SDK validators, so `warn: file_delete:*` -- the rule shape this
+  release makes useful -- now validates cleanly.
+- Semantic-class coverage for destructive shell commands is partial (#1905).
+  `_SHELL_CLASS_MAP` deliberately excludes `dd`, `rsync`, `git`, `tar`, `awk`,
+  `openssl`, `sed` and every interpreter (`python`, `node`, `bash`, ...), so
+  `dd of=...`, `git clean -xfd`, `rsync --delete` and
+  `python -c "shutil.rmtree(...)"` classify as empty and match NO semantic-class
+  rule. A `file_delete` rule does not see destructive shell deletion in general.
+
 ## 1.13.6 (2026-07-12): interpreter-pinned hook command (P0)
 
 ### Fixed

{controlzero-1.13.7 → controlzero-1.13.9}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: controlzero
-Version: 1.13.7
+Version: 1.13.9
 Summary: AI agent governance: policies, audit, and observability for tool calls. Works locally with no signup.
 Project-URL: Homepage, https://controlzero.ai
 Project-URL: Documentation, https://docs.controlzero.ai

{controlzero-1.13.7 → controlzero-1.13.9}/controlzero/__init__.py

@@ -41,7 +41,7 @@ from controlzero.hitl.grant_protocol import (
 from controlzero.policy_loader import load_policy
 from controlzero.secrets import SecretRef, SecretStr, secret_ref
 
-__version__ = "1.13.7"
+__version__ = "1.13.9"
 
 __all__ = [
     "Client",

{controlzero-1.13.7 → controlzero-1.13.9}/controlzero/_internal/_messages.py

@@ -131,6 +131,51 @@ SYSTEM_MESSAGES: dict[str, dict[str, str]] = {
             "마스킹되지 않은 값을 전달하는 대신 차단합니다(기본 차단)."
         ),
     },
+    # DLP mask on a host whose hook protocol cannot accept rewritten tool input
+    # (every host except Claude Code + Gemini CLI). The mask escalates to a
+    # deny, and THIS is the text the model reads on that deny -- so it is
+    # written as an INSTRUCTION to the agent, not as a status line for a human.
+    # Goal: the agent re-issues the same call with the sensitive value removed,
+    # so the user's task completes in one extra round-trip instead of dead-
+    # ending. See controlzero/_internal/dlp_remediation.py.
+    #
+    # {findings} is TYPE + LOCATION only. It NEVER contains the detected value:
+    # echoing the secret into the model's context is the exact disclosure DLP
+    # exists to prevent (#1881, "PII never in cleartext").
+    #
+    # NO ``ko`` ENTRY, deliberately. The Korean pack is a professional draft
+    # pending customer review (see the module docstring), and an unreviewed
+    # machine translation of a SECURITY INSTRUCTION is worse than the English
+    # fallback -- a mistranslated "do not re-send the value" is a leak. Korean
+    # locales fall back to ``en``, which is exactly what they get today from the
+    # hard-coded English this replaces, so there is no regression to fix later.
+    "DLP_MASK_UNSUPPORTED:agent": {
+        "en": (
+            "Blocked: the tool arguments contain sensitive data, and this "
+            "agent host cannot accept redacted arguments, so the call was "
+            "blocked instead of masked. Findings: {findings}. To proceed, "
+            "retry the SAME call with the sensitive value removed -- refer to "
+            "it indirectly (an environment variable the tool expands, a "
+            "secret-manager reference, or a file path the tool reads) instead "
+            "of inlining it. Do not print, echo, restate, or re-send the value "
+            "in any form, including in a summary or an explanation."
+        ),
+    },
+    # Location-free fallback: a mask matched on the flattened argument text but
+    # no single argument leaf carries it (a pattern spanning the boundary
+    # between two concatenated values). Still actionable, just less precise.
+    "DLP_MASK_UNSUPPORTED:base": {
+        "en": (
+            "Blocked: the tool arguments contain sensitive data, and this "
+            "agent host cannot accept redacted arguments, so the call was "
+            "blocked instead of masked. To proceed, retry the SAME call with "
+            "the sensitive value removed -- refer to it indirectly (an "
+            "environment variable the tool expands, a secret-manager "
+            "reference, or a file path the tool reads) instead of inlining it. "
+            "Do not print, echo, restate, or re-send the value in any form, "
+            "including in a summary or an explanation."
+        ),
+    },
     # Tamper / quarantine (constructed in client.py + cli/main.py).
     "BUNDLE_TAMPERED": {
         "en": (

{controlzero-1.13.7 → controlzero-1.13.9}/controlzero/_internal/action_aliases.py

@@ -39,7 +39,7 @@ modern intent is silently broken.
 from __future__ import annotations
 
 import json
-from typing import Iterable
+from collections.abc import Iterable
 
 # Tool covered by this alias table. Currently only "database" carries
 # the legacy <-> canonical split; other tools were added post-#350 and

{controlzero-1.13.7 → controlzero-1.13.9}/controlzero/_internal/action_validator.py

@@ -23,10 +23,10 @@ pass.
 """
 from __future__ import annotations
 
-from typing import Iterable
+from collections.abc import Iterable
 
-from controlzero._internal.action_aliases import TOOL as _ALIAS_TOOL
 from controlzero._internal.action_aliases import _AMBIGUOUS, _CLASSES
+from controlzero._internal.action_aliases import TOOL as _ALIAS_TOOL
 
 # Mirror of the canonical tool set + host-aliases the extractors
 # accept. Source of truth is tool_extractors.json; this list is
@@ -34,6 +34,16 @@ from controlzero._internal.action_aliases import _AMBIGUOUS, _CLASSES
 _CANONICAL_TOOLS: set[str] = {
     "Bash", "database", "http", "web_search", "browser",
     "file_read", "file_write", "file_search", "task",
+    # Shell semantic-class NAMESPACES (#437). The evaluator promotes a shell
+    # command's danger class into its own namespace as `<class>:<class>`
+    # (enforcer.py `evaluate`), so `file_delete:*` and `network:*` are
+    # first-class rule actions exactly like the `file_read:*` / `file_write:*`
+    # siblings already listed above. #437 registered two of the four classes
+    # and missed these two, so the shipped "Shell Command Restrictions"
+    # dashboard template warned "not a known canonical action" on rules that
+    # were in fact firing correctly (#1904). Warn-only path; no decision
+    # depends on this set.
+    "file_delete", "network",
     # database aliases
     "sql", "Database", "PostgreSQL", "MySQL", "postgres", "sqlite",
     # Bash aliases
@@ -61,6 +71,14 @@ _DATABASE_TOOL_ALIASES = {
     "database", "sql", "Database", "PostgreSQL", "MySQL", "postgres", "sqlite",
 }
 
+# Context-sensitive namespaces the evaluator promotes for a shell call
+# (#1734): `git <sub> ... <ref>` becomes `git_<sub>:<target>` and
+# `aws|gcloud|kubectl <sub>` becomes `<cli>:<sub>`. The git subcommand set is
+# open (any `git_*` tool token is a promoted action), so it is matched by
+# prefix rather than enumerated.
+_GIT_ACTION_TOOL_PREFIX = "git_"
+_CLOUD_CLI_TOOLS = {"aws", "gcloud", "kubectl"}
+
 
 def _build_known_database_methods() -> set[str]:
     out: set[str] = {"*"}
@@ -87,6 +105,9 @@ def is_known_action(action: str) -> bool:
     tool, _, method = action.partition(":")
     if tool == "*":
         return True
+    # #1734 promoted namespaces: git_<sub>:<target>, <cloud_cli>:<sub>.
+    if tool.startswith(_GIT_ACTION_TOOL_PREFIX) or tool in _CLOUD_CLI_TOOLS:
+        return True
     if tool not in _CANONICAL_TOOLS:
         return False
     if method == "*" or method == "":

{controlzero-1.13.7 → controlzero-1.13.9}/controlzero/_internal/bundle.py

@@ -322,6 +322,7 @@ def _zstd_decompress(data: bytes) -> bytes:
     # Preferred: `zstandard` is the de-facto PyPI package.
     try:
         import io
+
         import zstandard as zstd
 
         dctx = zstd.ZstdDecompressor()
@@ -620,7 +621,7 @@ def translate_to_local_policy(
     :func:`controlzero.policy_loader.load_policy`: a dict with
     ``version: "1"`` and a flat ``rules`` list where each entry is
     either ``{"deny": "<tool>"}``, ``{"allow": "<tool>"}`` or
-    ``{"effect": "<deny|allow|warn|audit>", "action": "<tool>"}``.
+    ``{"effect": "<deny|allow|warn>", "action": "<tool>"}``.
 
     Policies are sorted by ``priority`` DESCENDING (higher number = higher
     precedence = evaluated first; first-match-wins), so SDKs in every language
@@ -961,15 +962,22 @@ def _translate_rule(rule: dict, policy_id: str) -> Optional[dict]:
     # behavior) turned an unknown rule into allow-*-for-its-pattern -- a
     # fail-open for a security gate (#1303). A deny here over-denies that one
     # pattern at worst, which is the safe direction.
+    #
+    # ALL_EFFECTS is the single source of truth for that vocabulary (#1927);
+    # DLP_SCANNED_EFFECTS is derived from it by subtraction, so any effect that
+    # can reach a decision from here is DLP-scanned by default. Lazy import:
+    # enforcer imports from this file.
+    from controlzero._internal.enforcer import ALL_EFFECTS
+
     effect_raw = rule.get("effect")
     if not effect_raw:
         # Only fall back to rule["action"] for effect if it looks like
         # one of the canonical effects. Otherwise "action" is a tool
         # name and we should not use it here.
         fallback = rule.get("action")
-        if fallback in ("allow", "deny", "warn", "audit"):
+        if fallback in ALL_EFFECTS:
             effect_raw = fallback
-    effect = effect_raw if effect_raw in ("allow", "deny", "warn", "audit") else "deny"
+    effect = effect_raw if effect_raw in ALL_EFFECTS else "deny"
 
     # Tool pattern resolution order:
     #   1. plural ``actions`` (list, as emitted by the backend)
@@ -992,7 +1000,7 @@ def _translate_rule(rule: dict, policy_id: str) -> Optional[dict]:
         # it is NOT a canonical effect name (effect already captured
         # above).
         candidate = rule.get("action")
-        if candidate and candidate not in ("allow", "deny", "warn", "audit"):
+        if candidate and candidate not in ALL_EFFECTS:
             patterns = [str(candidate)]
 
     if not patterns:

{controlzero-1.13.7 → controlzero-1.13.9}/controlzero/_internal/credential_hook.py

@@ -39,7 +39,6 @@ from typing import Any, Literal
 from controlzero._internal.credential_scanner import scan_for_credentials
 from controlzero.errors import CredentialLeakBlocked
 
-
 Action = Literal["warn", "redact", "block"]
 Source = Literal["tool_output", "tool_stderr", "file_read", "grep_match"]
 

{controlzero-1.13.7 → controlzero-1.13.9}/controlzero/_internal/credential_scanner.py

@@ -34,7 +34,6 @@ from functools import lru_cache
 from importlib import resources
 from typing import Any, Optional
 
-
 # Default per-occurrence byte cap for marker-block patterns that omit
 # `max_block_bytes`. Matches the Rust scanner's
 # `DEFAULT_MAX_BLOCK_BYTES` constant; 8192 bytes covers every PEM