Post (slot Fri 2026-10-23): How Do You Catch an AI's Silent Permission Change Before It Ships? The Access-Matrix Snapshot Gate, on a 7-Entry CRM #270

Filing gate ③: a task the maintainer directed. This card is part of slate 1 of the daily cadence (ruling B, #267, 「B」, 2026-10-17). It was filed by the repo:www.objectos.ai seat (objectstack-ai/objectstack#12224), session session_01FeA1nwBz1ohH65dvffUGKr. Priority: P1 · fast topic.

Slot

Fri 2026-10-23, date: 2026-10-23. This is a tentative daily slot on the shared calendar on #267. It holds once the approved queue reaches 7 and the cadence switches to daily. If the switch-over slips, the seat re-dates the post before merging and moves any back-linked updated with it. Merge on the slot day only.

The topic (from the seat's slate 1, read-only research at objectstack origin/main be076dad2 and objectos origin/main 76988dad4)

Working title: How Do You Catch an AI's Silent Permission Change Before It Ships? The Access-Matrix Snapshot Gate, on a 7-Entry CRM

Audience / topic: developer / governance

Angle. The published review post says, of allowDelete: false → true, "No rule fires. Both values are valid; both are enforceable." That is true of os validate. There is one gate that does fire, if the app opts in: a committed (permission set × object) matrix that os compile re-derives from metadata and diffs against the snapshot, failing the build with a semantic line until a human regenerates it — "its diff IS the review artifact." Ownable concept: effective capability, not raw flags (the matrix reports what a set can actually do, View/Modify All folded in, each row carrying the object's OWD). Not covered: zero posts mention the access matrix. how-to-review-ai-generated-app-changes stops at "nothing in the metadata expresses whether sales reps should delete opportunities"; this post is the next step: the change still needs a human, but it can no longer be silent. #262/#263 is about a field change reaching projections; this is a grant change reaching the build.

Proof artifact. On examples/app-crm, which is opted in (access-matrix.json, 7 entries across crm_sales_user and guest_portal): flip allowDelete: false → true for crm_opportunity in src/security/sales-positions.ts:50, run npx os compile → the drift failure (✗ Access matrix drift (1 change) … 'crm_sales_user' gains access to 'crm_opportunity' (delete)), then npx os compile --update-access-matrix and git diff examples/app-crm/access-matrix.json → the one-line "delete": false → true. One edit, one drift line, one reviewable diff. (CLI build failure + real diff.)

Sources:

• content/docs/permissions/access-matrix.mdx:7-12 — "the (permission set × object) matrix is derived purely from metadata on every os compile, diffed against a committed snapshot, and any drift fails the build with a semantic explanation until a human regenerates the snapshot."; :16-24 opt-in (os compile --update-access-matrix; "Both examples/app-crm and examples/app-showcase are opted in."); :26-43 the drift output ("its diff IS the review artifact"); :47-72 snapshot format, "the matrix reports effective capability, not the raw flags"; :74-85 relation to the posture linter and the explain engine.
• content/docs/permissions/explain.mdx:106-108 — the matrix is "the same evaluation run over representative (permission set × object) pairs; explain is the per-decision zoom lens."
• examples/app-crm/access-matrix.json (7 entries; every crm_sales_user row has "delete": false); src/security/sales-positions.ts:44-62.
• www content/blog/how-to-review-ai-generated-app-changes/index.mdx:112 — "allowDelete: false → true. No rule fires."

Internal links: how-to-review-ai-generated-app-changes, objectos-agent-permission-boundaries, glossary reviewable-diff, declared-vs-enforced.

Risk. The gate runs in os compile, not os validate — never write that validate catches it. Quote the drift line from the real run; the doc's example is the showcase app. Frame it as "one gate, opted in", not as a correction of the review post (that post's sentence stays true of os validate); whether the review post gets an updated cross-link is the seat's call and goes on the card, not in the post.

House bar (every post)

• Runs on what readers install. Produce every transcript, count and diff on the version that npm view @objectstack/cli dist-tags reports as latest on the day the proof is run (18.1.0 as of 2026-10-26; maintainer ruling on Publishing cadence: one post a day, switched on once seven approved posts are queued (maintainer ruling B, 2026-10-17) — charter change, shared calendar, writing capacity #267, 2026-10-26). npm create objectstack@latest installs that version.
  • Use the CRM example at the matching tag @objectstack/cli@<latest>, or a fresh scaffold from npm create objectstack@latest.
  • Name the measured version in the post. Never pin an older version in the title, description or footer.
  • If a behaviour the topic needs is missing or different on that version, stop and report it. Do not write about unreleased behaviour.
• Sourcing.
  • Every claim is sourced to a public line: objectstack or objectos, at the tag or origin/main, with the line quoted in the PR body.
  • The private cloud repository is never cited.
  • No competitor claim goes beyond what a public source says.
  • No pricing, signup URL or edition naming ([Decision] Pricing headline: www shows $20 / $45 per AI seat "billed annually (about two months free)", docs License & Pricing shows $24 / $54 per month with no annual price — which is the source, and is the annual discount real? #214 and [Decision] Where does "Get started" go? Neither site has an ObjectOS Cloud signup URL, so every plan CTA loops www → docs → www #215 are pending).
• Charter.
  • Writing rules 1–9 apply: a query-shaped title, one number, and no template shape shared with this week's other posts.
  • The canonical strings come from src/lib/positioning.ts.
  • The token figures are retired (Adopt objectstack's 2026-10-03 positioning across www.objectos.ai: copy changes, five posts, an update sweep #209 Q5).
• Locales. All eight. zh-Hant is produced only by pnpm gen:zh-hant. Covers and diagrams follow the asset rule (one English-text set plus the zh pair), each with a cover and at least one diagram that adds information the cover lacks.
• Gates. pnpm content:lint, --published, check, build (tree clean afterwards) and seo:smoke.
• Browser check.
  • Check the article in en and zh-Hans plus the blog list.
  • Viewports: 1366×625, 1440×750, 1512×830, 1920×945, 390×844 and 360×800, in light and dark.
  • Scroll lazy images into view first, then look at the shots.
  • Render every new SVG at native size on light and dark.
• Internal links as listed above. If a published post gets a back-link, set its updated to this post's slot date.

Generated by Claude Code