proof-harness 0.1.0-next.7 → 0.1.0-next.9

package/COMPATIBILITY.md

@@ -11,7 +11,7 @@ Consumers must pin an exact prerelease version, for example:
 ```json
 {
   "devDependencies": {
-    "proof-harness": "0.1.0-next.6"
+    "proof-harness": "0.1.0-next.8"
   }
 }
 ```
@@ -27,9 +27,253 @@ versions rather than guessing how to interpret them.
 
 ## Prerelease migration notes
 
-### Unreleased audit hardening
+### 0.1.0-next.9 — anonymous actions and control sensitivity (release candidate)
 
-Release candidate `0.1.0-next.7` tightens acceptance behavior; it has not been published. Trace
+Prepared for release; not yet published. After publication, pin exactly
+`proof-harness@0.1.0-next.9` and regenerate capabilities and baseline traces.
+Trace/mission/health versions remain unchanged. Authentication refusal and
+control-sensitivity output contracts use protocol/schema version 1.
+
+#### Anonymous self-service actions (#23)
+
+`assert.authorization` accepts `actor: "anonymous"` for **action probes only**.
+It sends the protected POST invoker request in a fresh API context, without
+login cookies or Authorization, and disables redirect following. It does not
+clear or reuse the authenticated page session. Use the Playwright project's
+`use.baseURL`, an explicit `action.baseURL`, or an already navigated page URL.
+
+```ts
+await assert.authorization({
+  actor: "anonymous", page,
+  action: {
+    module: "user-management", name: "selfDeleteAccount", inputParams: {},
+    expectedAuthRedirect: "/sign-in",
+  },
+});
+```
+
+The consumer must update its **guarded invoker**, after request validation and
+registered-handler lookup. In the catch around actual handler execution:
+
+```ts
+import { authenticationRedirectResponse } from "proof-harness/server";
+// Existing proofGuard, body validation, registry lookup, and handler call stay.
+const refusal = authenticationRedirectResponse(error, request, {
+  module: body.module, action: body.action, allowedRedirects: ["/sign-in"],
+});
+if (refusal) return refusal;
+// Keep the existing failure response for all other exceptions.
+```
+
+Choose the exact authentication destination from the consumer's own auth
+middleware. The adapter recognizes Next.js redirect errors only, requires no
+Cookie/Authorization request headers, and matches an exact allowlisted relative
+URL. It returns HTTP 401 with `{ protocolVersion: 1,
+ type: "proof_action_auth_refusal", module, action,
+ reason: "authentication_required", redirect }`. The client binds that envelope
+to the invoked action and the assertion checks `expectedAuthRedirect`.
+A generic 401/500, `action_threw`, invalid-form rejection, unexpected redirect,
+malformed result, or missing registry entry is incomplete evidence. Anonymous
+success is a failed authorization assertion. No seeded denied role is needed.
+
+Use `assert.actionSucceeds` with a disposable authenticated actor for the
+allowed-path control; account-deletion fixtures remain consumer-owned. The
+adapter's destination list and placement are protected trust inputs: it must
+only normalize authentication redirects from an executed registered action,
+not invoker setup errors or unrelated redirects. This is not automatic proof
+of an arbitrary application's authentication semantics.
+
+Workspace scope discovery now follows local caller-input bindings and accesses,
+including destructuring aliases and direct parse/safeParse results. It no
+longer counts comments, SQL/output keys, or generated/result workspace IDs.
+Unknown user-input dataflow used as workspace scope and dynamic input keys
+remain unassessed. Internal `_BOT.ts` actions retain their existing exemption
+from caller-boundary coverage. This is bounded local analysis, not intermodule
+schema inference. In particular `createTeamWorkspace` no longer inherits a
+cross-tenant requirement merely because it returns a new workspace ID. Declare
+any additional product invariants and add their proofs in the consumer.
+
+#### Separate positive-control sensitivity (#24)
+
+Move the old `TENANT-deny-all` entry out of the primary mutation catalog into
+a separate protected module named by `controlSensitivityCatalog` in
+`proof.config.mjs`. Keep its existing subject, apply SQL and spec; add:
+
+```js
+claims: [],
+controls: [{
+  kind: "tenant_isolation", target: "workspace_members", operation: "select",
+  emittedBy: "assert.tenantIsolation",
+}],
+expectedFailureCode: "tenant_isolation_control",
+```
+
+Run `proof-harness controls --inventory`, then `proof-harness controls` (or
+`--only TENANT-deny-all`). Both require fresh passing baseline evidence for
+every mapped package-origin **control** in the selected spec. The initial
+contract supports tenant-isolation SELECT controls emitted by
+`assert.tenantIsolation` or `assert.authorization`, with the exact failure code
+`tenant_isolation_control`. Other sensitivity categories remain unsupported.
+
+The runner reuses mutation planting/readback, isolated execution, restoration,
+and recovery checks. A successful test needs a non-timeout failed proof, a
+failed mapped control assertion of the same helper origin, and a step error
+beginning with that exact failure code. Setup errors, incomplete/skipped
+assertions, another spec, primary-only failures, or a missing failed control do
+not count. Unexpected owner-control database errors are setup failures rather
+than control rejection; explicit permission denial or zero visible owner rows
+can establish the intended anti-vacuity failure.
+
+Results live separately in `artifacts.controlSensitivity` (default
+`.proof/control-sensitivity`), with `mode: "control-sensitivity"`,
+`controlRejected`/`controlsTurnedRed`, and `detected: false`. They remain planted
+traces and cannot satisfy baseline claims or primary mutation coverage. Use
+`proof-harness controls --recover` for an interrupted run against the same
+local stack; the shared recovery journal blocks either runner until restored.
+Primary `mutate` still rejects `claims: []` with no resolved primary baseline.
+A failed control can no longer count as a failed primary claim of the same
+kind/target/operation. Wire both commands into consumer CI if both properties
+are required.
+
+### 0.1.0-next.8
+
+Published release `0.1.0-next.8`. Consumers pin exactly
+`proof-harness@0.1.0-next.8` when adopting these features.
+
+#### Direct RLS clients and Auth administration (#18)
+
+The scanner recognizes immutable local bindings returned by
+`createSupabaseRLSClient`, including named-import aliases and awaited calls.
+Their table writes are assessed as RLS writes, never recorded as service-role
+writes. Binding identity is local to its scope: shadowed identifiers,
+reassignment, escaped clients/builders, and unresolved privilege still fail.
+This remains convention-based discovery of the named consumer factories, not
+verification of their implementation or arbitrary wrapper/dataflow analysis.
+
+Direct `serviceClient.auth.admin.deleteUser(...)` is recorded in the additive
+capability field `serviceRoleAuthOperations: ["deleteUser"]`, separate from
+`serviceRoleMutations`. This does not pretend the Auth API is a SQL DELETE
+(and does not infer whether its optional soft-delete argument is true).
+Other administrative methods, dynamic method names, detached calls, and
+unresolved administrative privilege remain unassessed.
+
+Regenerate capabilities. Changes to Auth operations participate in drift under
+`service_role_mutations_changed`. Coverage requires a package-origin denial
+assertion and an allowed-path control for a user-facing Auth-admin action,
+even when it has no workspace input or voluntary invariant declaration.
+Existing explicit action-gap policy handling remains unchanged; a recognized
+operation alone is not passing authorization evidence. Trace, mission and
+health protocol versions are unchanged; capability schema remains additive v1.
+
+#### Catalog providers and rollback INSERT controls (#19, #20)
+
+These changes are not in the published `0.1.0-next.7`. They are opt-in; the
+default SQL parser and REST INSERT/DELETE control remain available. No trace,
+mission, or health protocol version changes. Pin exactly `0.1.0-next.8` only
+after it is released.
+
+#### Catalog assessment
+
+Set `schemaProvider: "scripts/proof/catalog-provider.mjs"` in the protected
+`proof.config.mjs`. `parse`, the parse step of `build`, and both sides of
+`drift` use it instead of the conservative SQL parser. ALTER and DROP are then
+evaluated by PostgreSQL, not inferred from historical CREATE statements.
+
+The module must export a default async function receiving:
+
+- `protocolVersion: 1`, `rootDir` for the tree being assessed;
+- `migrations`: ordered `{ path, sql, sha256 }` entries from the configured
+  migration directory (top-level `.sql` files), and their combined `inputHash`;
+- `withLocalPostgres(connectionUrl, callback)` and
+  `readPostgresCatalog(client, schemas = ["public"])` from `proof-harness/node`.
+  These are injected so the archived base needs no installed dependencies to
+  import these helpers. Keep the provider's own imports dependency-free.
+
+The consumer provider must create an empty disposable database, apply its
+versioned platform bootstrap and every supplied migration in order, read the
+catalog, and drop the database in `finally`. Fail on migration or cleanup
+errors. Return `{ protocolVersion: 1, assessed: true, issues: [], tables }` only
+after successful evaluation and cleanup; `tables` is the helper's result.
+The connection helper restricts connections to loopback hosts. The consumer
+owns the local database URL, creation privileges, platform bootstrap, migration
+ordering, schema selection, and any required role setup. Never use the live
+head database as the base catalog, clone an application-populated database,
+or catch a failed migration and return partial facts.
+
+Catalog table facts contain `schema`, `name`, `columns` (names), `rls_enabled`,
+`rls_forced`, and `policies`. Each policy contains `name`, `command`, `roles`,
+`mode`, `using`, and `check`. Classification is package-owned. Drift compares
+column names, RLS state including FORCE, and full policy facts; this does not
+add drift coverage for column types, defaults, functions, triggers, or grants.
+Malformed envelopes/facts and changed migration inputs fail assessment and
+replace stale successful output with an unassessed artifact.
+
+The schema artifact adds `assessment` with provider protocol/path/hash,
+migration paths/hashes, combined input hash, and repository source hash. This
+is source identity, not a signature. The provider, its platform bootstrap,
+configuration, and installed harness remain protected trust inputs.
+
+For generated migrations, retain `driftPrepare` to rebuild them in each tree.
+**Adoption requires a preparatory base commit:** register the provider, its
+platform bootstrap, and config in the consumer before the comparison that
+upgrades the package. Both base and head must declare a provider. Drift rejects
+switching assessment modes across the comparison and never substitutes head
+configuration for a base without the provider. Existing next.7 ignores the new
+keys; registering them does not repair its conservative parser. A consumer
+already blocked on next.7 needs to land this trusted setup separately before
+the candidate's first successful drift run.
+
+#### Append-only INSERT controls
+
+Configure the protected consumer config explicitly, using your local ports:
+
+```js
+insertControl: {
+  mode: "rollback",
+  databaseUrlEnv: "PROOF_DATABASE_URL",
+  role: "service_role",
+  supabaseUrl: "http://127.0.0.1:54321",
+}
+```
+
+Supply the corresponding local PostgreSQL URL through that environment
+variable; never commit its password. The configured REST origin must match
+`NEXT_PUBLIC_SUPABASE_URL`. The database URL must refer to the same stack,
+schema, and migrations as REST; the harness validates the configured origin
+but cannot discover which database a REST server actually serves.
+
+The denied INSERT still executes through the authenticated Supabase client.
+Only after an explicit `42501` denial and a service read confirming no write
+does the harness validate the same payload on one PostgreSQL connection:
+BEGIN, SET LOCAL ROLE, INSERT, force deferred constraints, ROLLBACK. The role
+must have the intended INSERT permission. Missing columns keep their database
+defaults; the harness supplies no tenancy values. An invalid payload, failed
+role change, database error, or unacknowledged rollback fails as incomplete
+evidence. The harness records the control assertion only after success and a
+REST reread confirming no matching row remains. There is no consumer callback
+that can stamp a passing control.
+
+No DELETE privilege is needed for this control. Transactional trigger writes
+also roll back, but sequence advancement and external side effects do not;
+use only a disposable local stack. This control checks database validity under
+the configured role, not REST middleware or an authenticated user's JWT
+context. Templates whose privileged insert depends on that context must supply
+a suitable database design/control strategy rather than treat this mode as
+equivalent. Product authorization errors must still use SQLSTATE `42501`;
+generic exceptions such as `P0001` are not accepted as authorization evidence.
+
+For maintainers, `PROOF_DATABASE_URL=... node tests/postgres-integration.mjs`
+after `pnpm build` exercises a separate temporary database against PostgreSQL,
+including immediate and deferred failures and catalog ALTER/DROP behavior.
+
+### 0.1.0-next.7 — audit hardening
+
+Published release `0.1.0-next.7` tightens acceptance behavior. Trace
+<a id="unreleased-audit-hardening"></a>
+
+### 0.1.0-next.7
+
+Published September 7, 2026. This release tightens acceptance behavior. Trace
 schema remains 2, with additive source/execution identity fields. Version 1
 and unversioned trace shapes remain explicitly readable, but CLI acceptance
 requires current provenance. Required consumer changes:

package/PROOF_SDK_CONTRACT.md

@@ -24,7 +24,7 @@ instead; this document is for anyone _consuming_ the template.
 
 ## Current acceptance semantics
 
-The unreleased audit hardening in [COMPATIBILITY.md](COMPATIBILITY.md#unreleased-audit-hardening)
+The `0.1.0-next.7` audit hardening in [COMPATIBILITY.md](COMPATIBILITY.md#010-next7)
 supersedes older template-specific command examples below. Trace consumers
 must use `decodeTrace`/`decodeTraceBundle` for structural validation and
 `readTraceDirectory` for CLI-equivalent freshness checks. Evidence counts only
@@ -1221,3 +1221,48 @@ a trace version bump.
 `.proof/coverage-policy.json` carries its own `schemaVersion` (currently `1`).
 It is authored, not derived, and is read only by `pnpm proof:coverage`; consumers
 do not need to parse it.
+
+
+## Catalog provider and rollback controls (0.1.0-next.8)
+
+The protected consumer config may opt into `schemaProvider` protocol 1 and
+`insertControl.mode: "rollback"`. See [the setup and migration contract](COMPATIBILITY.md)
+for the exact provider envelope, base-commit requirements, and control configuration.
+`proof-harness/node` exports `withLocalPostgres`, `readPostgresCatalog`,
+`rollbackInsertControl`, and the `PostgresCatalogTable`/`PostgresCatalogPolicy` types.
+Providers own database materialization; the harness validates catalog facts,
+classifies policies, binds source identity, and compares both trees. A rollback
+INSERT control is package-executed and can only record passing control evidence
+after its insert, deferred checks, rollback, and absence reread succeed. The
+original authenticated request remains the primary authorization assertion.
+
+
+## Direct Auth administration (0.1.0-next.8)
+
+Capability schema v1 adds optional `serviceRoleAuthOperations`, currently a
+closed list containing only `"deleteUser"`. It describes direct service-client
+Auth API calls separately from `serviceRoleMutations` (SQL table writes).
+Such user-facing actions require denial and allowed-control evidence in
+coverage even without a workspace input. Changes use the existing
+`service_role_mutations_changed` drift facet. See `COMPATIBILITY.md` for
+supported factory/binding shapes and required consumer regeneration.
+
+
+## Anonymous invocations and control sensitivity (0.1.0-next.9 candidate)
+
+The versioned anonymous refusal envelope is `ActionAuthenticationRefusal`
+(protocol 1), validated by `isActionAuthenticationRefusal` from the shared
+entry point. The server exports `authenticationRedirectResponse`; Playwright
+exports `actAsUser.invokeAnonymousAction` and accepts `actor: "anonymous"` in
+`assert.authorization` action probes. Only an action-bound, expected
+authentication redirect can establish a passing anonymous denial; generic
+exceptions are not evidence. See `COMPATIBILITY.md` for the required protected
+invoker integration and allowed authenticated control.
+
+`proof-harness controls` consumes `controlSensitivityCatalog` independently
+from primary mutation inventory and writes `mode: "control-sensitivity"`
+results under `artifacts.controlSensitivity`. Its mapped failed controls never
+count as primary mutation detection. The initial contract is limited to
+tenant-isolation SELECT anti-vacuity checks with `tenant_isolation_control`;
+see `COMPATIBILITY.md` for exact selectors, fresh baseline requirements and
+recovery. Consumer claims and product fixtures remain consumer-owned.

package/README.md

@@ -17,13 +17,13 @@ Public prereleases are published under the npm `next` tag. Pin an exact
 prerelease version while the API is stabilizing:
 
 ```sh
-pnpm add proof-harness@0.1.0-next.6
+pnpm add proof-harness@0.1.0-next.8
 ```
 
 The package exposes environment-specific entry points:
 
 - `proof-harness/shared` — portable types and vocabularies
-- `proof-harness/node` — Node mission validation helpers
+- `proof-harness/node` — Node mission validation and local PostgreSQL helpers
 - `proof-harness/playwright` — Playwright proof assertions and traces
 - `proof-harness/server` — server-side fixtures, guards, and service clients
 - `proof-harness/portable-vocabulary` — dependency-free runtime constants
@@ -61,7 +61,7 @@ code via `allowProofServiceHosts`; there is deliberately no environment
 override.
 
 The package also provides one `proof-harness` executable with `scan`, `parse`,
-`registry`, `build`, `verify`, `coverage`, `inventory`, `drift`, and `mutate`
+`registry`, `build`, `verify`, `coverage`, `inventory`, `drift`, `mutate`, and `controls`
 subcommands. Commands read repository paths from
 `proof.config.mjs`; without one they use a conventional application layout.
 Product migration aggregation and explicit mutation definitions remain
@@ -92,16 +92,28 @@ The package is released from this public repository with npm provenance.
 Prerelease consumers must pin an exact version rather than using `next`, `^`, or
 `~`; see [COMPATIBILITY.md](./COMPATIBILITY.md) for the compatibility policy.
 
-## Audit hardening (0.1.0-next.7, unreleased)
+## Audit hardening (0.1.0-next.7)
 
-The working branch adds shared fail-closed trace ingestion, source freshness,
+This release adds shared fail-closed trace ingestion, source freshness,
 stronger authorization probes, isolated mutation evidence and interruption
 recovery, conservative discovery, and package-owned drift regeneration.
-See [required migration changes](COMPATIBILITY.md#unreleased-audit-hardening)
+See [required migration changes](COMPATIBILITY.md#010-next7--audit-hardening)
 before upgrading a consumer. In particular, existing traces must be rerun and
 unsupported SQL now blocks assessment.
 
+Release `0.1.0-next.8` adds direct RLS client and Auth-admin discovery,
+a consumer-owned catalog provider for full SQL histories, and transactional
+INSERT controls for append-only tables. Pin exactly
+`proof-harness@0.1.0-next.8`. See [compatibility and setup](COMPATIBILITY.md#010-next8)
+for the required consumer changes.
+
 The harness establishes specific tested claims. Acceptance still requires
 consumer-owned requirements and a trusted CI job that controls the harness,
 policies, and evidence. A passing trace is not a general proof of code quality
 or a defense against an executor that can rewrite the acceptance gate.
+
+
+Release candidate `0.1.0-next.9` adds isolated anonymous action probes and a
+separate positive-control sensitivity runner. It also distinguishes caller
+workspace inputs from generated result IDs. See [next.9 setup and migration](COMPATIBILITY.md)
+before upgrading; consumer invoker and catalog changes are required.

package/cli/config.mjs

@@ -9,6 +9,7 @@ const DEFAULT_CONFIG = Object.freeze({
     traces: ".proof/traces",
     drift: ".proof/drift.json",
     mutations: ".proof/mutations",
+    controlSensitivity: ".proof/control-sensitivity",
   },
   // The module-descriptor system (module.meta.ts → modules.json and its
   // checker) moved to the consumer template in 0.1.0-next.6: it serves the
@@ -46,8 +47,11 @@ const DEFAULT_CONFIG = Object.freeze({
   // Optional consumer-owned argv used to prepare generated migration inputs
   // in both the working tree and the archived base before parsing.
   driftPrepare: null,
+  schemaProvider: null,
+  insertControl: null,
   driftSources: ["app", "package.json"],
   mutationCatalog: null,
+  controlSensitivityCatalog: null,
 });
 
 function mergeConfig(config = {}) {

package/cli/engines/parse_proof_schema.mjs

@@ -40,6 +40,8 @@ import fs from "node:fs";
 import path from "node:path";
 import { pathToFileURL } from "node:url";
 
+import { assessWithProvider } from "./proof_schema_provider.mjs";
+import { classifyTable } from "./proof_schema_classification.mjs";
 import { loadProofConfig } from "../config.mjs";
 
 const CONFIG = await loadProofConfig();
@@ -283,87 +285,12 @@ function parsePolicies(sql, sourceFile) {
 // Classification
 // ---------------------------------------------------------------------------
 
-function policyIndicatesWorkspace(policy) {
-  const body = `${policy.using} ${policy.check}`.toLowerCase();
-  if (body.includes("get_user_workspace_ids(")) return true;
-  if (
-    /workspace_id\s+in\s*\(\s*select\s+workspace_id\s+from\s+workspace_members/i.test(
-      `${policy.using} ${policy.check}`,
-    )
-  ) {
-    return true;
-  }
-  return false;
-}
-
-function policyIndicatesUser(policy) {
-  const body = `${policy.using} ${policy.check}`;
-  // user_id = auth.uid() OR auth.uid() = user_id OR owner/created_by variants
-  const patterns = [
-    /\b(user_id|owner_id|created_by|invited_by)\s*=\s*\(?\s*(select\s+)?auth\.uid\(\)/i,
-    /\bauth\.uid\(\)\s*=\s*(user_id|owner_id|created_by|invited_by)\b/i,
-    /\(\s*select\s+auth\.uid\(\)\s*\)\s*=\s*(user_id|owner_id|created_by|invited_by)\b/i,
-    /\b(user_id|owner_id|created_by|invited_by)\s*=\s*\(\s*select\s+auth\.uid\(\)\s*\)/i,
-  ];
-  return patterns.some((re) => re.test(body));
-}
-
-function policyIsPublicRead(policy) {
-  if (policy.command !== "SELECT") return false;
-  const body = policy.using.trim().toLowerCase();
-  return body === "true";
-}
-
-function classifyTable(policies) {
-  // No policies at all → admin_only (assumes RLS-enabled Supabase table
-  // without authenticated access).
-  if (policies.length === 0) return "admin_only";
-
-  // A policy with no TO clause defaults to `TO public` in Postgres, so
-  // treat an empty `roles` list as implicit public (i.e. authenticated
-  // users are subject to it). This matches the common
-  // `CREATE POLICY foo ON t FOR SELECT USING (...)` pattern.
-  const isAuthFacing = (p) =>
-    p.roles.length === 0 ||
-    p.roles.some((r) => r === "authenticated" || r === "public");
-  const authPolicies = policies.filter(isAuthFacing);
-  const serviceOnly =
-    authPolicies.length === 0 &&
-    policies.length > 0 &&
-    policies.every(
-      (p) => p.roles.length === 1 && p.roles[0] === "service_role",
-    );
-
-  if (serviceOnly) return "service_only";
-
-  // Check workspace first (most specific).
-  if (authPolicies.some(policyIndicatesWorkspace)) return "workspace_scoped";
-  if (authPolicies.some(policyIndicatesUser)) return "user_scoped";
-
-  // public_read: every authenticated-accessible policy is SELECT with
-  // USING (true). (Don't classify as public_read if any write policy
-  // targets authenticated, that's a different pattern.)
-  const readPolicies = authPolicies.filter(
-    (p) => p.command === "SELECT" || p.command === "ALL",
-  );
-  if (
-    readPolicies.length > 0 &&
-    readPolicies.every(policyIsPublicRead) &&
-    authPolicies.every((p) => p.command === "SELECT")
-  ) {
-    return "public_read";
-  }
-
-  if (authPolicies.length === 0) return "admin_only";
-
-  return "unclassified";
-}
-
 // ---------------------------------------------------------------------------
 // Main
 // ---------------------------------------------------------------------------
 
-export function main() {
+export async function main() {
+  if (CONFIG.schemaProvider) return assessWithProvider(CONFIG);
   const sources = readAllMigrations();
   const unsupported = [];
   const enabledTables = new Set();
@@ -487,5 +414,5 @@ const invokedDirectly =
   import.meta.url === pathToFileURL(process.argv[1]).href;
 
 if (invokedDirectly) {
-  main();
+  await main();
 }

package/cli/engines/proof_control_sensitivity.mjs

@@ -0,0 +1,95 @@
+const assertionHelpers = new Set([
+  "assert.tenantIsolation",
+  "assert.authorization",
+  "assert.actionSucceeds",
+  "assert.httpResponse",
+]);
+const helpers = new Set(["assert.tenantIsolation", "assert.authorization"]);
+const primary = (a) =>
+  a.role === undefined ||
+  a.role === null ||
+  ["primary", "negative"].includes(a.role);
+const control = (a) => ["control", "positive_control"].includes(a.role);
+const decisive = (a) => a.status !== "incomplete" && a.status !== "skipped";
+const matches = (a, s) =>
+  a.kind === s.kind &&
+  a.target === s.target &&
+  a.operation === s.operation &&
+  (!s.emittedBy || a.emittedBy === s.emittedBy);
+
+export function validateControlBaseline(mutation, traces) {
+  if (
+    !Array.isArray(mutation.claims) ||
+    mutation.claims.length ||
+    !Array.isArray(mutation.controls) ||
+    !mutation.controls.length ||
+    mutation.expectedFailureCode !== "tenant_isolation_control"
+  )
+    throw new Error(
+      `[PROOF_FAIL] control_contract: ${mutation.id} requires claims: [], nonempty controls, and expectedFailureCode: tenant_isolation_control`,
+    );
+  for (const selector of mutation.controls) {
+    if (
+      selector.kind !== "tenant_isolation" ||
+      selector.operation !== "select" ||
+      typeof selector.target !== "string" ||
+      !selector.target ||
+      !helpers.has(selector.emittedBy)
+    )
+      throw new Error(
+        `[PROOF_FAIL] control_contract: ${mutation.id} has an unsupported control selector`,
+      );
+    const exists = traces.some(
+      (t) =>
+        t.specFile === mutation.spec &&
+        t.passed === true &&
+        !t.mutation &&
+        t.steps.some(
+          (step) =>
+            step.passed === true &&
+            (step.assertions ?? []).some(
+              (a) =>
+                a.passed === true &&
+                decisive(a) &&
+                control(a) &&
+                matches(a, selector),
+            ),
+        ),
+    );
+    if (!exists)
+      throw new Error(
+        `[PROOF_FAIL] control_baseline_missing: ${mutation.id} has no fresh passing package-origin control for ${selector.target}`,
+      );
+  }
+  return mutation.controls;
+}
+
+/** Control failures cannot satisfy primary claim detection, even for the same key. */
+export function assertionSelectorsTurnedRed(
+  traces,
+  selectors,
+  role,
+  expectedFailureCode,
+) {
+  if (!selectors.length) return false;
+  return selectors.every((selector) =>
+    traces.some(
+      (t) =>
+        t.passed === false &&
+        t.steps.some(
+          (step) =>
+            step.passed === false &&
+            (!expectedFailureCode ||
+              step.error?.startsWith(`[PROOF_FAIL] ${expectedFailureCode}:`)) &&
+            (step.assertions ?? []).some(
+              (a) =>
+                a.passed === false &&
+                decisive(a) &&
+                (role === "control" ? control(a) : primary(a)) &&
+                assertionHelpers.has(a.emittedBy) &&
+                matches(a, selector),
+            ),
+        ),
+    ),
+  );
+}

package/cli/engines/proof_coverage.mjs

@@ -352,6 +352,8 @@ function buildReport() {
   // user_scoped by their owner policy, but a service-role action accepting an
   // arbitrary workspaceId still needs an action-layer cross-tenant probe.
   //
+  // Auth administrative operations require this boundary independently of
+  // workspace inputs because their target may be another user.
   // A denial alone is not enough. A broken/unregistered action also refuses
   // everyone, so the same action target needs a passing allowed-path control.
   const denialKinds = new Set(["authorization", "tenant_isolation"]);
@@ -366,14 +368,17 @@ function buildReport() {
     `${a.module}:${a.name}`.localeCompare(`${b.module}:${b.name}`),
   )) {
     if (
-      capability.acceptsWorkspaceId !== true ||
+      (capability.acceptsWorkspaceId !== true &&
+        !(capability.serviceRoleAuthOperations ?? []).length) ||
       capability.internalOnly === true
     ) {
       continue;
     }
 
     const workspaceMutations = capability.serviceRoleMutations ?? [];
-    if (workspaceMutations.length === 0) continue;
+    const authOperations = capability.serviceRoleAuthOperations ?? [];
+    if (workspaceMutations.length === 0 && authOperations.length === 0)
+      continue;
 
     const action = `${capability.module}:${capability.name}`;
     const denialEvidence = assertions.filter(
@@ -404,6 +409,7 @@ function buildReport() {
       action,
       tables: [...new Set(workspaceMutations.map((m) => m.table))].sort(),
       mutations: workspaceMutations,
+      authOperations,
       denial: denialProven ? "proven" : "gap",
       control: controlProven ? "proven" : "gap",
       status: proven ? "proven" : acceptance ? "accepted_gap" : "gap",
@@ -593,13 +599,20 @@ function printReport(report) {
     );
     heading(
       "SERVICE-ROLE ACTION BOUNDARIES",
-      "Derived from caller-controlled workspaceId inputs plus service-role mutations. Each action needs both an unauthorized/cross-tenant refusal and an allowed-path control; withProof metadata is not consulted.",
+      "Derived from workspace-targeted service-role writes or privileged Auth operations. Each action needs both an unauthorized/cross-tenant refusal and an allowed-path control; withProof metadata is not consulted.",
     );
     console.log("");
     printTable(
       [
         { header: "action", get: (r) => r.action },
-        { header: "tables", get: (r) => r.tables.join(",") },
+        {
+          header: "effects",
+          get: (r) =>
+            [
+              ...r.tables,
+              ...r.authOperations.map((op) => `auth.admin.${op}`),
+            ].join(","),
+        },
         { header: "denial", get: (r) => r.denial },
         { header: "control", get: (r) => r.control },
         { header: "status", get: (r) => r.status },
@@ -767,7 +780,7 @@ gap or an unproven action requirement.`);
   if (serviceRoleActionGaps.length > 0) {
     problems.push({
       line:
-        `[PROOF_FAIL] service_role_action_gap: ${serviceRoleActionGaps.length} workspace-targeted service-role action(s) lack mandatory action evidence: ` +
+        `[PROOF_FAIL] service_role_action_gap: ${serviceRoleActionGaps.length} privileged action(s) lack mandatory action evidence: ` +
         serviceRoleActionGaps
           .map((g) => {
             const missing = [