Authorization Policy Matrix

KilnCMS authorizes every resource action through Ash.Policy.Authorizer. This document is the per-resource reference for who may do what — the source of truth is each resource's policies do … end block; this table mirrors it and is backed by the policy test suite (test/kiln_cms/**/​*_policies_test.exs plus policies_test.exs / version_policies_test.exs).

Roles

The role attribute on KilnCMS.Accounts.User (lib/kiln_cms/accounts/user.ex) has three values:

Audiences (the read axis)

role gates authoring. A separate, orthogonal audience axis gates which signed-in end-users may read a published record — the consumer-facing access model (cf. Directus role-based read access). Configured via config :kiln_cms, :audiences (KilnCMS.CMS.Audiences); :public is always implied.

• Each content record carries one audience (default :public).
• Each user carries a set of audiences, assigned by an admin via :manage_access — or granted by an active paid membership (#337 Phase 2), through a system-only recompute. Never self-service either way.
• Audiences resolve per organization (KilnCMS.Accounts.Scoping.audiences/2, applied by KilnCMS.CMS.Checks.InAudience): a member's OrgMembership.audiences for the site being served; [] for an actor affiliated elsewhere but not here (fail-closed, since the org comes from a client-controlled host); [] for an account with no memberships at all. The global User.audiences column is read by no policy: its fallback for membership-less accounts was removed at 1.0 (#1543), and a post-deploy job moves such accounts onto a default-org membership carrying it.
• A published record is readable when its audience is :public, or its audience is one the reader holds on that org. Editors/admins see everything.

So the content read row below is :public-published for anonymous/viewer; audience-restricted published rows additionally require membership.

Two non-role actors also appear below:

• anonymous — no actor (authorize?: true with no actor:); the public site / headless API.

• system — trusted internal callers: workers, Oban jobs, the AshOban scheduler, delivery-path bookkeeping, mix tasks. Not a role, because it is not a person: it is either %KilnCMS.SystemActor{} running under the policies (see The system actor below — the direction of travel, #1402) or, still, a raw authorize?: false that runs around them.

  Because a raw bypass skips every policy on the resource, each remaining site is a piece of the authorization surface this matrix does not show. So each one has to say why it is safe, with a marker directly above the call (or inside it):

  # authorize?: false — delivery: `:public_by_slug` filters published +
  # audience + unlock itself, and `tenant:` scopes it to this site.
  CMS.get_published_page_by_slug!(slug, locale, args, authorize?: false, tenant: org)

  The dash is — or --, and the reason must say something — at least three words: a delivery action whose own filter carries the published/audience/ unlock grant, a tenant already scoped by the router, a pre-auth flow with no actor, a system read of display data on a self-only-read resource. "Directly above" means the comment block touching the statement the call is part of (above x =, a pipeline's head, a with clause, a case pattern); a marker above a def ... do does not reach into its body. A comment that only mentions a bypass (multitenancy :bypass, "the admin bypass above") justifies nothing (#1739). One marker covers one call: a second bypass pasted under a justified one — or a pipeline that reads and then loads — needs its own. mix kiln.authz.check (part of mix precommit and CI) fails on a site without one (#1309, #1739).

  The gate covers all of lib/ (#1402). Files that predate the system-actor migration and still carry unexplained bypasses are listed in the task's @backlog with the exact count each one has — 129 files, 313 sites when that landed. It is a ratchet, not an exemption: a file with no entry must be clean, so new code is gated from the day it lands; a listed file may not gain a site; and a listed file that loses one fails too, with the number to write, because an allowance nobody maintains stops being a ratchet. Nothing may be added. Emptying it finishes #1402.

The system actor

%KilnCMS.SystemActor{} (lib/kiln_cms/system_actor.ex) is the actor a worker, an Oban job, a delivery-path bookkeeping write or a mix task passes instead of authorize?: false. KilnCMS.Checks.SystemActor is the policy check that admits it. The actor answers who, never which org: a system call still passes tenant: explicitly and multitenancy strategy :attribute is untouched.

It is not a privilege boundary against our own code — any module that can build a system actor could have written authorize?: false instead. Three things it does buy:

1. The grant is declared where every other grant is, so this document can list it. The table below is enforced: KilnCMS.PolicyCoverageTest fails the build when a resource admits Checks.SystemActor without a row here.
2. A policy added tomorrow still applies. An authorize_if clause grants exactly the policy it sits in; a bypass (and authorize?: false) grants everything, forever, including policies that do not exist yet.
3. Validations, changes and the tenant filter keep running, exactly as they do for a person.

Admitted with authorize_if, never bypass. A bypass Checks.SystemActor is the same standing grant authorize?: false gave, only spelled differently, and it would swallow every policy declared beneath it — including ones a later PR adds, which is the thing this exists to stop. PolicyCoverageTest fails the build on a system-actor bypass. (The one top-of-stack clause that IS right is bypass AshOban.Checks.AshObanInteraction on publish_scheduled: there the caller genuinely is the AshOban scheduler and Ash itself vouches for it from the trigger metadata on the changeset, rather than from an actor the caller chose. Prefer that check wherever the caller is the scheduler.)

Ash ANDs policies, so on a resource with a broad action_type(:update) policy written for people, a second policy admitting system code changes nothing — the broad one still refuses — and widening it would grant system every update on the resource. The answer is still not a bypass: narrow the grant inside the policy that would otherwise refuse, with action/1 as a check.

policy action_type([:create, :update]) do
  authorize_if KilnCMS.CMS.Checks.EditableContentType

  # System-only actions, and only those — each to its own caller.
  forbid_unless action([:reindex_search_text, :set_embedding])
  authorize_if {KilnCMS.Checks.SystemActor, subsystem: :firing, action: :reindex_search_text}
  authorize_if {KilnCMS.Checks.SystemActor, subsystem: :search, action: :set_embedding}
end

For a person the first clause has already decided; for a system actor every other action forbids at the second. Nothing is short-circuited.

Scope is per resource, action and subsystem (#1747). Every clause names the subsystems it admits — {KilnCMS.Checks.SystemActor, subsystem: [...]}, required, and a bare check fails the build — and those are the labels the calling code builds its actor with (SystemActor.new(:firing), a domain's system/0). Before #1747 the check matched any system actor, so a grant one worker needed was every worker's: admitting publishing to Task :complete let the automation worker complete anyone's task. The rules the grants follow:

• A write is admitted to exactly the subsystems whose code calls it. When two writes in one clause have different callers, action: narrows the clause (subsystem: :cms_bookkeeping, action: :complete).
• A read clause names every subsystem that reads through it. An action_type(:read) grant admits those subsystems to each read action on the resource, and the row lists every one.
• A label no clause names is admitted nowhere. :branding and :code_injection label their resolvers' reads of a row every visitor may read anyway, and no grant names them.

The Subsystems column is the machine-readable half of each row: groups of `action`, `action`: `:subsystem`, `:subsystem` separated by ·. It is enforced in both directions. KilnCMS.PolicyCoverageTest fails when a clause names a subsystem its row does not, and KilnCMS.SystemActorScopeTest asks Ash, for every action on every resource below and every subsystem label in the application, whether a system actor of that subsystem is admitted, and fails unless the answer is exactly this column: each named subsystem in, every other one out. CMS.Bookkeeping (:cms_bookkeeping) and CMS.Housekeeping (:cms_registry, :cms_settings, :releases, :promotion) stay separate labels because their grants barely overlap: folding them would hand the release worker publishing's task and redirect writes, and the reverse.

The struct carries no :id and no :role, so every actor-attribute check written for people resolves it to nothing: Scoping.effective_tier/2 returns :none, Scoping.audiences/2 returns []. A system actor can therefore only ever be authorized by an explicit clause below — or by a branch that admits everyone, the anonymous visitor included (published :public content, a :public settings row, a redirect).

Legend: ✅ allowed · ❌ forbidden · 🔎 allowed but row-filtered (reads return only the rows the policy permits, never an error) · ⚙️ system-only (authorize?: false).

Content — Page, Post, Entry (KilnCMS.CMS.Content macro)

Entry is the dynamic-content-type resource; it is generated from the same macro and so carries an identical policy stack. Everything below applies to all three, and to any content type a downstream project defines.

publish_scheduled is additionally allowed for the system AshOban scheduler via bypass AshOban.Checks.AshObanInteraction.

⚙️ Editors can publish, per site. SiteEditorialSettings.editors_can_publish (Checks.EditorMayPublish) lets an org's editors publish directly. /setup asks a new site, and admins change it under Team → Publishing. It defaults to off, so an upgraded site keeps admin approval until an admin turns it on. A read failure also answers "off" (KilnCMS.CMS.EditorialSettings). The content-type scope still applies: an editor limited to some types can publish only those.

Setting, moving or clearing scheduled_at takes the same permission as publish, because the scheduler publishes that date through its bypass with nobody checked at go-live.

Version history — Page.Version, Post.Version, Entry.Version (KilnCMS.CMS.VersionPolicies)

* forbid_if always() blocks manual create/update/destroy for every non-admin role; the admin bypass technically permits it, but in practice versions are written only by AshPaperTrail as a side effect of content actions (authorize?: false).

Taxonomy — Category, Tag, TagGroup

Taxonomy is world-readable because published content references it on the public / headless frontends.

Destroying a TagGroup does not destroy its tags — tags.tag_group_id is nilified, so they fall back to "Ungrouped" in the editor's picker.

Join tables — Tagging, ContentLink, RelatedLink

Tagging read is open so published content can load its tags; linking and unlinking is an editing action. Tagging has no domain code interface (it is managed through manage_relationship on the content resources).

A ContentLink names two documents, so since 1.1 (#1594) a reader below editor sees one only when they may read both its source and its target (Checks.LinkEndsReadable, which re-reads the ends under the reader's own authorization, the way Checks.DocumentReadable does for artifacts). It used to be world-readable, which let a published page's incoming_links name the drafts linking to it.

RelatedLink (#2025) is not a table of its own: it is content_links' curated kind: :related rows, read through a base filter, as the join of every related_<type>s relationship and of its write side curated_<type>s. Its policies are ContentLink's for people. The join read Ash runs behind those relationships is admitted as such (Checks.ThroughRelatedJoin): it never returns a row, and the related records are filtered by their own policy. It admits no system actor.

Media — MediaItem

Media is world-readable because published content embeds it (featured images, inline assets).

The alt-text publish gate (Validations.MediaAltText) reads the decorative flag as the system actor, through the plain read only (#1659); see The system actor.

The pipeline's own actions — record_processing, release_quarantine, adopt_into_image_backend and the cross-site quarantine_expired scan — are not an editor's. The first three are admin (bypass) or system actor only; quarantine_expired is the system actor's alone, admin included. See "The system actor" above.

The routes that serve a media item's bytes — /media/:id/download, /media/:id/stream and the on-the-fly transforms at /media/:id/t/:ops — all read the row through this policy under the request's session actor (MediaDownloadController.readable_item/2), so a gated item is a 404 on every one of them to anyone without its audience, and a quarantined item is a 404 to everyone. The transform route additionally refuses out-of-bounds parameters (an off-allowlist size or a bad signature) before it reads anything.

Webhooks — WebhookEndpoint

Endpoint configuration is admin-only. The delivery pipeline reads endpoints and keeps their health counters as the system actor (see The system actor); it cannot create, edit or delete one.

Mail settings — Mail.Settings

Instance-wide mail/DKIM configuration (/editor/mail) is admin-only. The delivery pipeline resolves the DKIM key as the system actor (KilnCMS.Mail.dkim_config/0), as does the lazy singleton creation (ensure_settings!/0); both are admitted for read and init only.

Provenance settings — Provenance.Settings

The instance's generated content-signing key (#1929) is platform-admin-only, for the same reason as Mail.Settings: the row is tenant-less. /setup generates it as the admin it has just created, and the overview's "served unsigned" strip offers the same action to a platform admin. There is no update or destroy: a key that signed manifests is never replaced in place. Signing reads the row as the system (authorize?: false via KilnCMS.Provenance.stored_key/0), as the billing checkout reads its credentials.

Billing settings — Billing.Settings

Instance-wide payment-provider credentials (/editor/billing) are platform-admin-only — deliberately not per-org, for the same reason as Mail.Settings: the row is tenant-less, so an org-admin check would resolve against the default org. The checkout path and webhook receiver read the row as the system (authorize?: false via KilnCMS.Billing.get_settings/0), as does the lazy singleton creation (ensure_settings!/0, reached from the admin page and from verify_credentials/1, which pre-checks its actor against this policy before doing anything).

Bounce suppression — Mail.SuppressedRecipient

Managed from /editor/mail (admin-only). The delivery pipeline writes suppressions on a hard bounce and consults them before queuing as the system actor (read and suppress only; a refused lookup fails closed and the recipient is not mailed). As with reads elsewhere, a non-admin read is filtered to nothing rather than erroring, so the list never leaks.

Custom fields — FieldDefinition

Defining the schema (fields per content type) is admin-only; editors read definitions so the content editor can render the inputs. Firing reads them to turn custom_fields values into JSON-LD, as %KilnCMS.SystemActor{} (#1402 — KilnCMS.Firing.CustomFields); the ApplyCustomFields write change still reads them with authorize?: false.

Analytics — ContentView, ContentViewDay, SearchQuery

record is forbid_if always() for every role — view/search counts are written only by the system delivery path (authorize?: false). Reading aggregates is editor/admin only (privacy-first: no per-user data is stored anyway). SearchQuery's record is written as a system actor instead (#1659), admitted by name; see The system actor.

Accounts — User, Token

User (lib/kiln_cms/accounts/user.ex):

"admin" throughout this section is KilnCMS.Accounts.Checks.PlatformAdmin: the effective platform role, which counts a temporary admin grant only until it expires — re-checked at authorization, so a long-lived LiveView or GraphQL socket's actor stops authorizing the moment its grant runs out. :manage_access and :grant_temporary_role additionally carry Validations.StandingAdminOnly: a temporary admin passes the policy but cannot confer or extend a tier.

Field policy: the role field is visible only to admins or the user themselves; other readers see the record without role. granted_role and granted_role_expires_at are public? false and so reach no API surface at all — field policies cover only public fields, which is why they are not listed beside role there. Nothing copies a grant into role on read, so the role a reader is allowed to see is always the standing one.

The three admin levers above are the account console's (account-administration.md). Two are refused for everyone, admins included:

NotLastAdmin sits on :manage_access and :anonymize as a validation, not a policy: admins bypass User's policies wholesale, so a forbid_if would never fire, and the refusal has to carry a sentence.

Demo mode (KILN_DEMO_RESET=confirm) narrows the self-service column: change_password and the TOTP actions (setup_totp, confirm_totp, disable_totp, regenerate_totp_recovery_codes) refuse every non-admin actor with DemoAccountLocked, as do Passkey.register and Passkey.destroy below. Every visitor to a demo is the same shared account. See demo-mode.md.

Token — every AshAuthentication action is gated to the AshAuthentication interaction bypass, and the nightly expunge trigger to the AshOban one. There are no caller-facing token actions.

That includes the revocation a password change or reset runs (#734): KilnCMS.Accounts.Changes.RevokeAllTokens reaches User.log_out_everywhere → Token.revoke_all_stored_for_subject through AshAuthentication.Strategy.action/4, which marks the call as AshAuthentication's own, so both resources' interaction bypasses admit it — no authorize?: false, and no system-actor grant. That matters for the anonymous half: :reset_password_with_token has no actor at all, only the emailed reset token its validation checks.

Three actions are ours rather than AshAuthentication's, and all three are forbid_if always() — no actor may reach any of them:

KilnCMS.Accounts.PendingSignIn calls all three with authorize?: false, because the whole point of both steps is that the caller has not finished signing in — there is no actor to authorize. The headless single-use guarantee and the #742 hold both depend on that flag, so a change that tightens authorize? handling has to keep these calls working.

The domain names them (spend_pending_sign_in, hold_first_factor_token, release_first_factor_token) plus get_stored_token_by_jti, a by-jti :read. A name is not an opening here: no policy matches :read either, so every one of them is refused without the authorize?: false only that module passes.

Your own sessions (#1823). The settings page's session list adds three self-service actions, all scoped by KilnCMS.Accounts.Checks.OwnsToken — a filter check matching rows whose subject is the actor's own. A row of another account is filtered out rather than refused, so a jti naming someone else's session lists nothing and revokes nothing. There is no admin bypass: an admin signs another account out with Sign out everywhere on the Accounts page.

Two more are bookkeeping and forbid_if always(), like the three above: :record_sign_in (the browser a session signed in from and its remember-me cookie's jti, by KilnCMSWeb.Plugs.SessionTracking) and :record_session_use (last_used_at, at most every five minutes, from a signed-in mount). KilnCMS.Accounts.Sessions calls both with authorize?: false, keyed by the jti in the signed session.

Platform accounts — Organization, OrgMembership, Role, ApiKey, Passkey, UserIdentity

These five resources gate on the platform role (actor_attribute_equals(:role, :admin)), not on OrgAdmin — they are the tenant registry and the credentials that sit above any one tenant, so "admin" here means platform admin.

Organization — no destroy action exists; organizations are deliberately not deletable.

The system actor may use the plain read only (#1659, see The system actor).

OrgMembership:

The AshOban grant is an unconditional bypass AshOban.Checks.AshObanInteraction at the top of the policies, not one scoped to expire_role_grant: the scheduler reads the rows to sweep through the primary read first, and a write-scoped grant leaves that read filtered to nothing. Every create/update also carries Validations.StandingAdminOnly, so a temporary platform admin cannot confer a site tier that would outlast its own grant.

The read grants above are why both resources scope their deny to write actions only: Ash AND-combines every applicable policy, so a bare policy always() would hard-forbid the self-read rather than filter it.

Role (per-org role definitions):

Scoping resolution itself reads roles as the system (authorize?: false).

ApiKey:

Minting returns the plaintext key exactly once; only the SHA-256 hash is stored. Sign-in looks the key up through the AshAuthentication interaction bypass.

Passkey:

register and bump_usage are forbid_if always() — the WebAuthn ceremony code writes them as the system.

UserIdentity — every action is forbidden to every role; only AshAuthentication's own OAuth machinery passes, via its interaction bypass.

Forms — Form, FormField, FormSubmission

Form:

active_by_slug is the public render path — it is what lets an anonymous visitor load a form. Building forms is an admin concern, like webhooks and field definitions.

FormField:

Anonymous reads stay open because fields render on public forms, but they now mirror the parent's visibility rather than being unconditional: the read policy filters on form.active == true, so the fields of an inactive form are no longer readable directly (#565 — previously the active flag was enforced only where forms are fetched, not on this resource).

One policy covers every read action deliberately. The public render path is Forms.get_active/2, which loads [:fields] as an anonymous but authorized read — and a relationship load runs the resource's primary :read, not :for_form. A narrower per-action grant would leave that load matching an editors-only policy and render the form with no fields at all, silently: a load filters rather than raises.

FormSubmission:

Submission contents are visitor-provided data, frequently PII — admin eyes only. The public submit path validates and then writes as the system (Forms.system/0, admitted to create alone — see "The system actor").

Redirects & branding — Redirect, SiteBranding, SiteSecurityTxt

All three are public information by design — delivery serves the same redirect map to anyone who hits an old URL, branding tokens render on every public page, and a site's security.txt row is the file /.well-known/security.txt serves (#1873). Both reads are tenant-scoped, so a request sees only its own site's rows. The slug-change hook that writes redirects runs as the system.

The destroy widening is for the content editor, which lists the redirects standing under the record being edited with a Delete on each: Checks.WritesRedirectTarget matches only a destroy on a loaded row, and decides it by re-asking the target's own :update policy as the actor — so a type-scoped editor cannot prune a redirect at a type they may not author, and a row whose target is gone or unregistered matches nobody (pruning dead rows stays an admin job on /editor/redirects).

Code injection — SiteCodeInjection (#490)

The row's contents are served verbatim to anonymous visitors, so the read policy says they are public rather than pretending otherwise. The history is not: "what the site serves now" and "who put it there, and what it said last week" are different questions with different audiences, so the version twin is org-admin only and has no writable action at all.

Writes are the tightest surface in this table for their size — this is stored XSS by design, so an org admin writing it is the whole authorization model. The second half of that model is not a policy: KilnCMSWeb.Plugs.CodeInjection runs only in the :delivery pipeline, so the snippet can never render in the editor console. See code-injection.md.

Object storage — SiteStorage, StorageProfile (#1559)

A site's own S3-compatible bucket, at /editor/site-storage. Org-admin on both sides, like every per-site integration; the rows name the site's storage provider and account. Profiles are written only through SiteStorage's saves, and uploads, downloads and media jobs read them as the system (KilnCMS.Storage.SiteProfiles), tenant-scoped to the item's own site — a media row can name only a profile of its own site.

There is no destroy on StorageProfile on purpose: media rows record the profile their file is in, and deleting one would strand every file in it. Moving the site to another bucket makes a new profile and leaves the old one.

As for the mail relay below, the stricter parts are not policies: the secret is encrypted, write-only and database-only; the endpoint must be https:// and is refused if it resolves to a private, loopback, link-local or metadata address, at save and on every connection; and a request to it carries nothing from the operator's ExAws config.

Outgoing mail — SiteMailRelay (#1322)

A site's own SMTP relay and From address, at /editor/site-mail. It is org-admin on both sides, like every per-site settings row. Nothing here is shown to a visitor, and the row names the site's mail provider and account. The delivery jobs read it as the system (KilnCMS.Mail.SiteRelay).

Org admin is the right tier, but on a hosted deployment an org admin is a tenant. That is why this row is stricter than the operator's Mail.Settings, and none of it is a policy. The password is encrypted and never read back into the form. It can't be pointed at an environment variable or a file, as the operator's keys can. The relay host is refused if it resolves to a private, loopback, link-local or metadata address, checked when it is saved and again on every connection. A site relay's hard rejects cancel the message but don't add the address to the instance-wide suppression list, because a relay the site chose could otherwise block any address for every site. They go on the site's own list instead (next section).

Site bounce suppression — Mail.SiteSuppressedRecipient (#1562)

The addresses one site's own relay rejected as dead, per site (org_id, email). Org admin reads and clears it from /editor/site-mail; a non-admin read filters to nothing. Only the delivery pipeline writes it, as the system actor, on a reject naming the recipient that came through that site's relay. Not even the site's admin can add a row: that would stop the site's mail to an address without a bounce ever happening.

It is consulted only for mail sent for that site (KilnCMS.Mail.suppressed?/2 with org_id:). Account mail carries no site and never reads it, and no site reads another's, so a hostile relay can stop only its own site's mail.

Push notification key — SiteVapidKey (#1560)

A site's own Web Push (VAPID) key pair, at /editor/site-push. Org-admin on both sides, like every per-site settings row. No action accepts a key: save mints the pair on first use and rotate replaces it, so a site admin can never set a key, only generate one. The private half is encrypted and never rendered. rotate and destroy delete the site's push subscriptions made against the old key as a system write, since those rows belong to the reviewers and not to the admin. KilnCMS.Push.Keys reads the row as the system, for the push worker (which has no actor) and for a reviewer subscribing on /editor/settings, who is not the site's admin.

Search instance — SiteMeilisearch (#1558)

A site's own Meilisearch instance — URL, API key and index — at /editor/site-search. Org-admin on both sides, like every per-site settings row; a read by anyone else is filtered to nothing. The indexing jobs and Meilisearch.search/2 read it as the system (KilnCMS.Search.Meilisearch.SiteInstance), tenant-scoped to the one site.

As with the site relay, the stricter parts are not policies: the key is encrypted, never read back into the form, and has no env-var or file source; the URL must be HTTPS and is refused if it resolves to a private, loopback, link-local or metadata address, at save and on every request (through KilnCMS.SafeFetch). "Reindex now" re-asks the update policy before enqueueing (#1166).

AI provider — SiteAiProvider (#1557)

A site's own AI provider, API key and model per feature (SEO suggestions, block assist, /api/ask answers), at /editor/site-ai. Org-admin on both sides, like SiteMailRelay: the row names the site's AI vendor and account. The features read it as the system (KilnCMS.LLM.SiteProvider) — /api/ask has no actor at all — tenant-scoped to the one site the request is for.

The same tenant rules as the mail relay, none of them a policy: the key is encrypted, never read back into the form, and has no env-var or file source; an OpenAI-compatible endpoint must be https:// and is refused if it resolves to a private, loopback, link-local or metadata address, at save and on every request. Changing the provider or endpoint drops the stored key, so a co-admin cannot send a key they were never shown to a host of their choosing.

Single sign-on — SiteSsoProvider, SiteSsoDomain (#1561)

A site's own OpenID Connect provider and the email domains it may vouch for, at /editor/site-sso. Org-admin on both sides; the sign-in path reads them as the system (KilnCMS.Accounts.SiteSso). verified_at is not writable: only :verify, after a DNS lookup that found the record, sets it.

The two User actions the sign-in uses — :sign_in_with_site_sso (mints the session token) and :register_with_site_sso (provisions a new account) — are forbid_if always() to every authorized caller. The platform-admin bypass would still pass that, so both also refuse any actor-carrying call in their own preparation/change: only SiteSso.Admission, with authorize?: false, reaches them, after the ID token, the verified domain and the cross-site rule have all passed.

Content types — TypeDefinition

Admins own the schema; editors read definitions so the editor UI can list dynamic types. Mirrors FieldDefinition. Firing and delivery read them as %KilnCMS.SystemActor{} (#1402), to resolve a dynamic document's public type name, its URL segment and its schema.org @type.

The same reads are routed read-only over JSON:API (/api/json/type-definitions, /by-name/:name, /:id, with include=field_definitions) and MCP (read_type_definitions), so an API key reads as its owner's tier on the host's org: editor+ lists, a viewer's key or no key gets an empty list. No write route exists on either surface.

Compliance — Consent, HistoryAnchor, DocumentEvent

Consent:

There is no update action — consent records are corrected by recording a new one, not by editing history.

The publish gate (Validations.RequiredConsent) reads a document's consents as the system actor, through for_content only (#1659); see The system actor.

HistoryAnchor — every action (read, for_content, create) is admin-only; there is deliberately no destroy. The publish pipeline writes anchors, and the chain reads them back, as Governance.system/0, admitted for create and for_content only (see The system actor). ChainCheckpoint and ChainCheckpointEntry are admin-only for people in the same way, and admit the system actor to their own lists of actions: recent, unwitnessed, create and record_publication on a checkpoint, and create, for_content and for_checkpoint on an entry. None of the three admits the plain read.

History.DocumentEvent:

Writes are refused to every role, admin included — the event log is append-only through the History API, which writes as History.system/0 (see The system actor), and has no destroy action at all.

Automation & newsletter

Automation.Rule, Newsletter.Subscriber, Newsletter.Segment, Newsletter.SegmentMembership, Newsletter.NewsletterSend all carry the same single policy: authorize_if OrgAdmin on every action. Admin-only across the board; editors, viewers and anonymous callers get nothing. Creating a campaign (Newsletter.send_as_newsletter/2) runs under that policy as the sender (#1655) — the console's tier check is UX, not the gate.

The public newsletter flows (subscribe, confirm, unsubscribe) run as the system behind signed-token checks. The send pipeline runs as the system actor (Newsletter.system/0; see The system actor), and the send guard reads the target segment as the sender. The two token reads (by_confirm_token, by_unsubscribe_token) declare multitenancy :bypass deliberately — the token is the secret, and the confirming visitor has no tenant context.

Delivery internals — PublishedArtifact, ReferenceEdge, BlockEmbedding, SyncExposure

These have no caller-facing write path: the firing engine, the search indexer and the sync API write them as the system, so nobody — admin included — can create, update or destroy one through a policy meant for people. All three now say so in the policy block rather than being reached around it: each admits %KilnCMS.SystemActor{} by name (#1402, and see The system actor). Search.TagEmbedding — absent from the table only because nothing caller-facing reads it — has the same shape.

All three used to read authorize_if always(). That was tightened in #565, and the reason it was safe is that every production reader is a system path: Firing.Delivery / Firing.Engine.read/4 for artifacts, Firing.References for the re-fire wave, Search.BlockIndexer / Search.BlockSearch / Search.Related for embeddings. What changed is what an actor-carrying caller sees. Every one of those system paths now carries %KilnCMS.SystemActor{} rather than authorize?: false.

PublishedArtifact is the one that mattered: it holds the rendered body of a document, so a blanket grant meant the audience axis enforced on Content was not re-enforced one tier down — paid, gated content was readable in artifact form. Its read now runs Firing.Checks.DocumentReadable, a manual (runtime) check that re-reads the source document under the caller's own authorization and keeps only the artifacts whose document came back. It delegates to the content policy instead of restating it, for two reasons: document_type is polymorphic (:page, :post, :entry for every dynamic type) with no relationship to join through, and a denormalized audience column would lag the document, because firing is asynchronous. Editors short-circuit the check.

The other two are enumeration surfaces — the link graph (including edges from unpublished drafts) and ancestor_context block text from every indexed document, drafts included — so they are simply editor-and-up.

In-app notifications — Notifications.Notification (#1320)

authorize_if expr(user_id == ^actor(:id)) is the whole read policy, and this is the one resource in the tree with no admin bypass at all. A notification list is a reading history — who was named in which review note, which drafts someone is watching — and a platform admin has no operational need for it. The sibling Accounts.PushSubscription does have an admin bypass (an operator has to be able to see where a device came from); this deliberately does not.

notify is the notifier's write, and it addresses somebody other than whoever acted, so it cannot be authorized against the acting user. Rather than calling it with authorize?: false, it is gated forbid_if actor_present() + authorize_if always(): the policy still runs and still decides, so an authenticated caller that reaches the action is refused by a rule a reader can see. KilnCMS.Notifications.record_in_app/1 is the only caller.

unread_about is the one read on the same terms, and for the same reason: before writing a review request, publish notice or return to draft, the notifier asks whether that recipient already has the same one waiting unread for the same document, and writes nothing if so (#1785). It answers about a recipient who is not the caller, so it is actor-less only. The self-only read policy names its three actions rather than action_type(:read), so a read added later matches no policy and is refused until it gets one.

An actor-less read (of the three self-only reads) is fail-closed for free: ^actor(:id) templates to nil, the filter reduces to user_id == NULL, and no row satisfies it.

Org-scoped (multitenancy strategy :attribute, attribute :org_id) — a user who edits two sites sees each site's notifications in that site's console only.

Saved views — CMS.SavedView (#1593)

A saved view is a named filter on the content list, so it is an editor's resource: forbid_unless OrgEditor heads every policy. An editor manages their own private views; sharing a view with the whole site, and editing or deleting a shared one, is an admin's (OrgAdmin bypass), so the team's view cannot be renamed out from under it by one member. Org-scoped like every console row: a view saved on one site is never listed on another.

Webhook deliveries — WebhookDelivery

Delivery history is admin-only. The delivery pipeline writes the row and its attempts as the system actor (never destroy), and the prune_deliveries and scrub_retraction_payloads AshOban triggers run under the AshObanInteraction bypass.

Propagation records — Propagation

Propagation records (#1927) are admin-only. The webhook pipeline opens and settles them and the CDN purge worker records the purge half, each as its system actor (never destroy); the prune_propagations AshOban trigger runs under the AshObanInteraction bypass.

The API-key axis

Role and audience are not the only axes. An actor authenticated by a kiln_… API key carries an immutable access scope, and two checks gate on it:

Applied as forbid_if clauses placed before the OrgAdmin bypass, so a key minted on an admin account cannot skip them:

The net rule: a :read key may read whatever its owner may read and write nothing; a :read_write key may author as its owner; no key may hard-delete anything, whoever owns it.

Block field policies — editable_by

A third, finer axis sits inside the block tree. A Kiln.Block field may declare editable_by: [roles] (Kiln.Block.Policy); absent that, any editor may edit it, and admins may edit everything. Today KilnCMS.Blocks.Quote declares field :featured, editable_by: [:admin].

Enforcement is at the resource boundary, not in the UI: KilnCMS.CMS.Changes.EnforceBlockFieldPolicy runs on every content create and update, so the write API's block_tree argument, MCP tools and GraphQL mutations are all covered — not just the editor form, which additionally filters the fields it renders. An existing block (matched by id) may keep whatever value it already had; a new block must carry the field's declared default.

Omitting a restricted field is not the same as setting it to its default, and used to be treated as if it were: a wholly id-less tree that leaves the field out now fails when any stored block of that type holds a non-default value, rather than silently clearing it (#566). The remedy the error names is to send each block's id — a tree carrying ids is judged block by block as before, so inserting a new block beside a restricted one is unaffected.

Nested children of a columns block are raw maps rather than union members, so they get no uuid_primary_key of their own. They are covered first by requiring the whole tree's multiset of role-restricted non-default nested values to be identical before and after a non-admin write (#774): such a value can be neither introduced nor dropped, but a column already holding an admin-set value may be resubmitted unchanged.

A count alone cannot say which child holds a value. The content editor stamps each nested child an "id", and where those ids exist the check binds each admin-set value to the child holding it (#865): a child returning under a known id must return with that id's value, and a child that held a restricted non-default value must return under the same id still holding it. Independently, an id naming two children in one submission is always refused — that collision would otherwise let a decoy satisfy the binding while the rendered child lost the value.

The binding is required, not gated (#954, #865): an id-less submission against an identified stored tree is refused, not silently downgraded to the count-only multiset. KilnCMS.CMS.Calculations.BlockIds is what makes that enforceable — it's what closed the gap that used to require gating (nested child ids were unreadable on a draft) — and it, along with the two narrow carve-outs that remain (restore_version, and a stored tree whose children never had ids to begin with), is documented in full at KilnCMS.CMS.Changes.EnforceBlockFieldPolicy's moduledoc rather than repeated here.

See residual risk 9 in threat-model.md for what this does and does not guarantee — in particular that a wholly id-less stored tree keeps the re-target until stamped, and that reusing another block's id remains open.

Coverage

Every resource registered in :ash_domains appears above. test/kiln_cms/policy_coverage_test.exs fails the build if a resource is ever added without Ash.Policy.Authorizer and a policies block — the failure mode that matters, since a resource with no authorizer is not merely unprotected but silently world-writable.