diff --git a/docs/e2e/feature-validation.tsv b/docs/e2e/feature-validation.tsv
index eca98484c..98e59b07d 100644
--- a/docs/e2e/feature-validation.tsv
+++ b/docs/e2e/feature-validation.tsv
@@ -83,7 +83,7 @@ MEDIA-004	Media metadata editing	As a media manager, I want to rename and tag me
 MEDIA-005	Media replace, delete, restore, and purge	As a media manager, I want to replace or remove assets safely so media library stays accurate.	POST /media/:id/replace overwrites bytes and updates the visible asset filename to the uploaded replacement name, DELETE soft-deletes active assets or purges trashed assets, POST /restore restores soft-deleted assets, and viewer/grid/trash actions reflect capabilities.	Replacing with wrong type; deleting asset used on published page; purge force; restore after purge; storage delete failure; upload queue overlay after upload; mobile context menu overlap with expanded sidebars.	replace requires media.replace; delete/purge requires media.delete; upload validation applies to replacement; route params decoded; Trash folder distinguishes restore vs purge actions.	server/handlers/cms/media.ts; src/admin/pages/media/components/ReplaceFileDialog; src/admin/pages/media/components/MediaViewerWindow; src/admin/pages/media/components/MediaGrid; src/ui/components/ContextMenu	Public pages may retain published references until republish/asset unavailable handling; replacement keeps one asset record but adopts replacement filename.	Happy: upload image, replace it, verify viewer reflects replacement, soft-delete from All files, restore from Trash, delete again, purge from Trash. Error: unsupported replacement. Boundary: restore soft-deleted asset. Invalid: missing file. Permission: replace/delete caps separate. Performance: replacement progress. Mobile: at 390px, Replace file dialog, media context-menu Delete, Trash navigation, and Restore remain usable without horizontal overflow.	MEDIA-005 replace/delete/restore/purge Playwright regression passed 2026-06-22; mobile replace/trash-restore and context-menu hit-test regression passed 2026-06-23; unsupported replacement, asset-in-use/public reference behavior, confirmation/safety review, and permission variants remain future expansion	0	None	MEDIA-005 promoted in `media.e2e.ts`: the desktop test signs in fresh, uploads disposable PNG, opens viewer, replaces file through Replace file dialog with a second PNG, verifies replacement filename and Replaced detail, closes viewer, deletes active asset from Media item options, verifies it leaves All files, opens Trash, restores it, verifies it leaves Trash and returns to All files, deletes it again, opens Trash, purges it from Media item options, and verifies Trash is empty. The mobile regression switches to 390x844, clears stored layout, uploads a disposable PNG, closes the Uploads floating window, opens the viewer, verifies mobile containment, opens Replace file, verifies the shared dialog is contained and the replacement picker is reachable, replaces the binary, verifies the replaced viewer remains contained, closes it, opens the item options menu by keyboard, deletes the asset, opens Trash, restores it, returns to All files, and verifies no page-level horizontal overflow. DEF-20260623-MEDIA005-01 closed: the point-anchored shared ContextMenu rendered inside the media canvas with viewport coordinates, so at 390px its clamped menu overlapped the expanded Folders sidebar while the sidebar intercepted pointer events; fixed by portaling the shared ContextMenu to document.body and covering that contract in `contextMenu.test.tsx`. Verification: focused `bun test src/__tests__/ui/contextMenu.test.tsx` passed 6/6 after first failing on the portal regression; focused `bun run test:e2e -- --project=e2e tests/e2e/media.e2e.ts -g "keeps replace and trash restore"` passed 2/2 including setup; full `bun run test:e2e -- --project=e2e tests/e2e/media.e2e.ts` passed 10/10 including setup. Run logs: docs/e2e/runs/2026-06-22-media005-replace-delete-restore.md; docs/e2e/runs/2026-06-23-media005-mobile-lifecycle.md.	2026-06-23
 MEDIA-006	Media storage adapters and migration	As an operator, I want to choose storage backends and understand migration state so media storage can move safely.	Media Storage panel loads from GET /media/storage, lists each media asset role with its elected adapter, defaults every role to Local disk (built-in), shows Local sharp ladder (built-in) when no variant delegate is elected, shows empty adapter/delegate states when no plugin storage surfaces are installed, exposes external adapter verification only for external adapters, and shows migration controls only when original/variant backlog exists.	Adapter unavailable; migration crash/retry; tab close cancel; partial migration; invalid delegate; no plugin adapters installed; no migration backlog on local-disk install; mobile panel overflow or clipped close controls.	Elect body role original/variant/avatar/font/plugin-pack and adapterId; delegate body string/null; migration body role and toAdapterId; storage.elect gates panel/list/elect/delegate/verify; storage.migrate gates migration stream.	server/handlers/cms/mediaStorageAdmin.ts; server/handlers/cms/mediaStorageMigration.ts; src/admin/pages/media/components/MediaSidebar; src/admin/pages/media/components/MediaStoragePanel; src/core/plugins/mediaStorageRegistry.ts	External adapters and delegates require plugin fixtures; local disk exists by default and clean installs have no migration backlog.	Happy: open Storage panel and verify local disk/local sharp defaults plus empty adapter/delegate states. Error: external verify failure. Boundary: no backlog hides migration. Invalid: unknown adapter/delegate. Permission: storage.elect/storage.migrate caps. Performance: storage snapshot loads quickly. Mobile: at 390px, storage panel opens, every built-in role combobox is reachable, delegate and empty adapter states can be scrolled into view, close control works, and no horizontal overflow appears.	MEDIA-006 built-in storage panel Playwright regression passed 2026-06-22; mobile storage panel layout regression passed 2026-06-23; external adapter verify/elect, migration backlog/progress, delegate plugin election, and storage.migrate permission variants remain future expansion	0	None	MEDIA-006 promoted in `media.e2e.ts`: the desktop test clears persisted media layout, signs in, opens `/admin/media`, opens the Storage panel, waits for `GET /admin/api/cms/media/storage`, verifies Backend per role is visible, every role combobox is `Local disk (built-in)`, Variant delegate is `Local sharp ladder (built-in)`, no delegate plugins and no external storage adapters empty states render, and `Test connection`/`Migrate` actions are absent on a clean local-disk install with no backlog. The mobile regression switches to 390x844, clears stored layout, opens the Storage panel, verifies the panel is viewport-contained without page-level horizontal overflow, verifies every built-in role combobox is visible and set to Local disk, scrolls to the Variant delegate and external-adapter empty states, verifies no `Test connection` or `Migrate` actions are present, closes the panel through the panel close control, and verifies the Storage rail action is reachable again. The first focused run exposed a test-selector issue only: both the rail toggle and panel header intentionally share the accessible name `Close Storage panel`, so the test now uses the existing `panel-close-media-storage` test id for the specific header close button. Verification: focused `bun run test:e2e -- --project=e2e tests/e2e/media.e2e.ts -g "built-in storage panel usable"` passed 2/2 including setup; full `bun run test:e2e -- --project=e2e tests/e2e/media.e2e.ts` passed 11/11 including setup. Run logs: docs/e2e/runs/2026-06-22-media006-storage-panel.md; docs/e2e/runs/2026-06-23-media006-mobile-storage-panel.md.	2026-06-23
 MEDIA-007	Image variants and public presentation	As a visitor/admin, I want media variants and public URLs to serve correctly so images load efficiently.	Image variant worker/protocol produces raster variants where applicable, media presentation maps asset public paths and variant paths for editor/published use, signed/storage URLs are redirected by public media routing, and SVG uploads are sanitized before bytes are stored and served.	Variant worker failure; SVG unsafe content; original missing; external signed URL expiry; media batch resolution; raster too small for variants; SVG made empty by sanitizer.	Variant protocol validates sizes/ids; SVG sanitizer strips script blocks, foreignObject, event handlers, javascript: URLs, and style blocks; public route serves trusted MIME based on server-chosen extension.	server/handlers/cms/imageVariantWorker.ts; server/handlers/cms/mediaVariants.ts; server/publish/mediaPresentation.ts; server/handlers/cms/svgSanitize.ts; server/handlers/cms/mediaUpload.ts; tests/e2e/media.e2e.ts	Some raster variants may be generated lazily or skipped for small images; SVGs intentionally do not get raster variant ladders.	Happy: upload unsafe SVG, verify asset appears, fetch served /uploads SVG, verify safe geometry remains and script/foreignObject/event/javascript/style vectors are stripped. Error: missing variant fallback. Boundary: SVG asset. Invalid: sanitizer-empty SVG rejected. Permission: public read for published assets, admin caps for manage. Performance: variant generation bounded. Mobile: responsive attrs correct.	MEDIA-007 unsafe SVG sanitizer/public media Playwright regression passed 2026-06-22; raster variant ladder/srcset, missing variant fallback, external signed URLs, media batch resolution, and responsive attrs remain future expansion	0	None	MEDIA-007 promoted in `media.e2e.ts`: test signs in, uploads an unsafe SVG through the Media workspace, verifies the asset tile appears, reads the tile preview /uploads URL, fetches the served SVG through Playwright's request context, verifies Content-Type is image/svg+xml, verifies safe <rect> geometry remains, and verifies <script>, <foreignObject>, event-handler attributes, javascript: URLs, and <style> blocks are absent from served bytes. Verification: focused `bun run test:e2e -- --project=e2e tests/e2e/media.e2e.ts -g "MEDIA-007"` passed 2/2 including setup; full `bun run test:e2e -- --project=e2e tests/e2e/media.e2e.ts` passed 8/8 including setup. Run log: docs/e2e/runs/2026-06-22-media007-svg-sanitizer.md.	2026-06-22
-PLUGIN-001	Plugin install and permission review	As an operator, I want to upload a plugin package or manifest and review requested permissions before install.	Plugins page accepts JSON/zip, inspect-package reads pending manifest, PermissionReviewSection shows permissions/grants, confirm installs assets/manifest and starts runtime.	Invalid zip; incompatible apiVersion; malformed manifest; permission/content access incoherence; package path traversal.	Manifest parser enforces id/version/apiVersion/permissions/resources/adminPages/settings/path/network patterns; install requires plugins.install and step-up where configured.	src/admin/pages/plugins/PluginsPage.tsx; server/handlers/cms/plugins/install.ts; server/handlers/cms/plugins/pack.ts; src/core/plugins/manifest.ts; server/plugins/package.ts	Package fixtures now cover happy ZIP install; malformed ZIP/path traversal remains lower-level.	Happy: install valid JSON manifest and ZIP package plugin. Error: invalid package specific error. Boundary: no permissions plugin. Invalid: traversal asset path. Permission: installer cap + step-up. Performance: upload/install feedback. Mobile: review readable.	CAP-005 plugin read/install affordance split, CAP-003 JSON-manifest install step-up, and packaged ZIP install smokes passed 2026-06-22; malformed ZIP/path traversal remains lower-level or future browser expansion	0	None	DEF-20260622-010 resolved: plugin reader users could see the Upload Plugin install control even though the server requires `plugins.install`; UI now hides upload/reinstall/remove/pack install unless `plugins.install` is granted. CAP-003 plugin install regression added: JSON manifest upload shows permission review, cancel and wrong step-up password leave the plugin absent, and correct step-up installs it. PLUGIN-001 package happy path is covered by packaged fixtures in `plugins.e2e.ts`: PLUGIN-002/003/004 upload in-memory ZIP packages, render permission review, complete step-up install, and verify installed plugin behavior. Verification: `bun run test:e2e -- --project=e2e tests/e2e/capabilities.e2e.ts -g "plugin capability"`, `bun run test:e2e -- --project=e2e tests/e2e/capabilities.e2e.ts -g "plugin install requires successful step-up"`, focused/full `tests/e2e/plugins.e2e.ts` runs including PLUGIN-002/003/004, `bun run lint`, `bun run build`, and `bun test` passed 5496/5496.	2026-06-22
+PLUGIN-001	Plugin install and permission review	As an operator, I want to upload a plugin package or manifest and review requested permissions before install.	Plugins page accepts JSON/zip, inspect-package reads pending manifest, PermissionReviewSection shows permissions/grants plus the manifest's contentAccess tables and networkAllowedHosts (diffed on upgrade), confirm installs assets/manifest and starts runtime.	Invalid zip; incompatible apiVersion; malformed manifest; permission/content access incoherence; package path traversal.	Manifest parser enforces id/version/apiVersion/permissions/resources/adminPages/settings/path/network patterns; install requires plugins.install and step-up where configured.	src/admin/pages/plugins/PluginsPage.tsx; server/handlers/cms/plugins/install.ts; server/handlers/cms/plugins/pack.ts; src/core/plugins/manifest.ts; server/plugins/package.ts	Package fixtures now cover happy ZIP install; malformed ZIP/path traversal remains lower-level.	Happy: install valid JSON manifest and ZIP package plugin. Error: invalid package specific error. Boundary: no permissions plugin. Invalid: traversal asset path. Permission: installer cap + step-up. Performance: upload/install feedback. Mobile: review readable.	CAP-005 plugin read/install affordance split, CAP-003 JSON-manifest install step-up, and packaged ZIP install smokes passed 2026-06-22; malformed ZIP/path traversal remains lower-level or future browser expansion	0	None	DEF-20260622-010 resolved: plugin reader users could see the Upload Plugin install control even though the server requires `plugins.install`; UI now hides upload/reinstall/remove/pack install unless `plugins.install` is granted. CAP-003 plugin install regression added: JSON manifest upload shows permission review, cancel and wrong step-up password leave the plugin absent, and correct step-up installs it. PLUGIN-001 package happy path is covered by packaged fixtures in `plugins.e2e.ts`: PLUGIN-002/003/004 upload in-memory ZIP packages, render permission review, complete step-up install, and verify installed plugin behavior. Verification: `bun run test:e2e -- --project=e2e tests/e2e/capabilities.e2e.ts -g "plugin capability"`, `bun run test:e2e -- --project=e2e tests/e2e/capabilities.e2e.ts -g "plugin install requires successful step-up"`, focused/full `tests/e2e/plugins.e2e.ts` runs including PLUGIN-002/003/004, `bun run lint`, `bun run build`, and `bun test` passed 5496/5496.	2026-06-22
 PLUGIN-002	Plugin lifecycle and uninstall	As an operator, I want to enable, disable, restart, and uninstall plugins so extension behaviour can be controlled.	PluginCard toggles enabled, restarts parked runtime, uninstall runs cleanup or force remove after failure, and UI refreshes plugin/admin pages.	Cleanup failure prompts remove anyway; disabling plugin removes admin pages/widgets/modules; restart sandbox error; busy state prevents duplicate clicks.	Lifecycle routes require plugins.lifecycle/configure/install depending action; runtime uses grantedPermissions; removal protects filesystem paths.	src/admin/pages/plugins/components/PluginCard; src/admin/pages/plugins/components/PluginRemoveDialog; server/handlers/cms/plugins/state.ts; server/handlers/cms/plugins/lifecycle.ts; server/plugins/runtime.ts	Plugin runtime errors are observable in UI; parked-error restart needs an error fixture.	Happy: install packaged fixture plugin, disable, verify runtime route unregistered, enable, verify runtime route restored, confirm uninstall, verify card and route are removed. Error: cleanup failure force path. Boundary: already disabled. Invalid: unknown plugin id. Permission: lifecycle/install caps. Performance: no stale cards. Mobile: card actions usable.	PLUGIN-002 packaged lifecycle browser smoke passed 2026-06-22; parked-error restart, uninstall-hook failure/force-remove, and mobile variants remain agent-run or lower-level	0	None	DEF-20260622-010 resolved: PluginCard lifecycle/install actions were rendered without checking `plugins.lifecycle` or `plugins.install`; UI now gates enable/disable/restart by `plugins.lifecycle` and uninstall by `plugins.install`. CAP-003 uninstall regression verifies cancel and wrong step-up password leave the manifest plugin installed, and correct password removes it. PLUGIN-002 promoted in `plugins.e2e.ts`: installs an in-memory ZIP plugin with a runtime route, verifies active route response, disables the plugin and verifies the card is Disabled plus the route returns 404, enables it and verifies the route returns 200 again, confirms the remove alertdialog, and verifies the card and route are gone. Initial focused run exposed a test-only selector mismatch: the dangerous remove confirmation is correctly `role="alertdialog"`, not `dialog`. Verification: focused `bun run test:e2e -- --project=e2e tests/e2e/plugins.e2e.ts -g "PLUGIN-002"` passed 2/2 including setup; full `bun run test:e2e -- --project=e2e tests/e2e/plugins.e2e.ts` passed 5/5 including setup, PLUGIN-008, PLUGIN-003, PLUGIN-002, and PLUGIN-004; TSV/matrix/diff guards passed; `bun run lint`, `bun run build`, and `bun test` passed 5496/5496. Run log: docs/e2e/runs/2026-06-22-plugin002-lifecycle.md.	2026-06-22
 PLUGIN-003	Plugin settings and secrets	As an operator, I want to edit plugin settings without leaking secrets so plugins can be configured safely.	Settings dialog loads masked settings, renders controls from manifest definitions, PUT updates values, restarts/pushes into VM, and secret values are never returned plainly.	Missing required setting; secret unchanged masked value; invalid number/select/color/url; plugin disabled.	Settings schema supports text, textarea, number, toggle, select, color, url, password; settings endpoint masks secrets and validates definitions.	src/admin/pages/plugins/components/PluginSettingsDialog; server/handlers/cms/plugins/settings.ts; src/core/plugins/manifest.ts	Plugin may receive settings.changed hook; fixture plugin with settings needed for full browser flow.	Happy: edit non-secret and secret setting. Error: invalid required setting. Boundary: min/max number. Invalid: unknown setting id. Permission: plugins.configure. Performance: save feedback. Mobile: dialog fits.	PLUGIN-003 settings/secrets browser smoke passed 2026-06-22; invalid setting payload, disabled-plugin, and mobile variants remain agent-run or lower-level	0	None	DEF-20260622-010 resolved: PluginCard settings action was visible without `plugins.configure`; UI now gates the settings affordance by `plugins.configure`, matching the server settings route policy. DEF-20260622-014 resolved: plugin admin UI stacked FormField adapters rendered visible labels without htmlFor/id, leaving settings inputs unnamed to assistive technology; PluginAdminUi now assigns generated ids to Input/Textarea/Select and passes htmlFor to FormField. PLUGIN-003 promoted in `plugins.e2e.ts`: installs a settings-only ZIP fixture, opens Settings, verifies the Mode default, saves a non-secret Mode and secret API token, reopens the dialog to verify Mode persistence and API token `***` masking, then calls the settings API and confirms the plaintext secret is absent. Verification: focused `bun run test:e2e -- --project=e2e tests/e2e/plugins.e2e.ts -g "PLUGIN-003"` passed 2/2 including setup; full `bun run test:e2e -- --project=e2e tests/e2e/plugins.e2e.ts` passed 4/4 including setup, PLUGIN-008, PLUGIN-003, and PLUGIN-004; TSV/matrix/diff guards passed; `bun run lint`, `bun run build`, and `bun test` passed 5496/5496. Run log: docs/e2e/runs/2026-06-22-plugin003-settings-secrets.md.	2026-06-22
 PLUGIN-004	Plugin admin pages, resources, and runtime routes	As an operator/plugin user, I want plugin-provided admin pages and resource records so extensions can expose UI/data.	Plugin admin pages render markdown/map/resource/app content; resource pages list/create/update/delete records through /plugins/:id/resources/:rid/records; runtime route proxies plugin server handler where allowed.	Missing plugin/page; disabled plugin; invalid resource record; app asset import failure; runtime route public vs authenticated policy.	Resource fields validate text/longtext/number/date/boolean and required; plugin route policy resolves caps; app asset paths pinned to plugin assetBasePath.	src/admin/pages/plugins/PluginPage.tsx; src/admin/pages/plugins/components/PluginPageRenderer; server/handlers/cms/plugins/records.ts; server/handlers/cms/plugins/index.ts	Plugin app pages use sandbox/host runtime, not arbitrary global access.	Happy: install packaged plugin, review permissions, open markdown/map/app/resource pages, create/delete resource record, and call authenticated runtime route. Error: disabled page unavailable. Boundary: empty resource plus required-title native validation. Invalid: missing required field. Permission: plugins.read/configure/install plus plugin admin.navigation/cms.routes/editor.code grants. Performance: app import loads. Mobile: page layout usable.	PLUGIN-004 packaged browser smoke passed 2026-06-22; disabled-plugin, runtime-denied, app-failure, and mobile variants remain agent-run or lower-level	0	None	PLUGIN-004 promoted in `plugins.e2e.ts`: the test logs in fresh, uploads an in-memory ZIP plugin, verifies permission review including unsandboxed app warning, completes step-up install, opens plugin markdown/map/app/resource admin pages, verifies the app asset imports, calls `/admin/api/cms/plugins/:id/runtime/status`, checks required resource-field validation, creates and deletes a resource record, and verifies the empty state returns. Verification: focused `bun run test:e2e -- --project=e2e tests/e2e/plugins.e2e.ts -g "PLUGIN-004"` passed 2/2 including setup; full `bun run test:e2e -- --project=e2e tests/e2e/plugins.e2e.ts` passed 3/3 including setup and PLUGIN-008. Run log: docs/e2e/runs/2026-06-22-plugin004-packaged-surfaces.md.	2026-06-22
diff --git a/docs/features/plugin-system.md b/docs/features/plugin-system.md
index a4e4f94a7..32d297776 100644
--- a/docs/features/plugin-system.md
+++ b/docs/features/plugin-system.md
@@ -684,6 +684,8 @@ Plugins read and write CMS content (pages, posts, custom tables) through `api.cm
 
 The manifest's `contentAccess[]` lists every table whose entries the plugin can touch, with per-table modes. The host fails closed without both the permission and the allowlist entry for entry reads/writes/publishes/deletes. `content.tables.create(...)` is different: it requires `cms.content.tables.manage`, creates a new user-managed table, and does not require a pre-existing `contentAccess[]` row for that table.
 
+The install/upgrade consent screen renders `contentAccess[]` in its own "Content tables" section, mirroring the "External hosts" section: every entry is listed with its modes (an `@own-created` entry renders as "Tables this plugin creates"), and on upgrade entries are diffed against the previously-installed manifest — a new table, or a new mode on an already-approved table, is badged as new; entries the update no longer requests show as dropped.
+
 ```jsonc
 {
   "permissions": ["cms.content.read", "cms.content.write"],
@@ -883,7 +885,7 @@ The DNS SSRF guard in `performGatedFetch` remains the load-bearing defense; the
 
 Permissions are requested in `plugin.json` and approved by the site owner at install time. Granted permissions are stored on the plugin row. Every SDK call checks the **granted** permission set, not just the request.
 
-The install endpoints enforce **grants = declared**, in both directions: every declared permission must be granted (install is all-or-nothing — there is no optional-permissions concept), and every granted permission must be declared (`assertPluginPermissionGrants` in `server/handlers/cms/plugins/shared.ts` rejects a tampered client that grants capabilities the manifest never disclosed). The install review dialog is shown for **every** install and upgrade — a zero-permission plugin renders "No permissions requested" rather than installing silently.
+The install endpoints enforce **grants = declared**, in both directions: every declared permission must be granted (install is all-or-nothing — there is no optional-permissions concept), and every granted permission must be declared (`assertPluginPermissionGrants` in `server/handlers/cms/plugins/shared.ts` rejects a tampered client that grants capabilities the manifest never disclosed). The install review dialog is shown for **every** install and upgrade — a zero-permission plugin renders "No permissions requested" rather than installing silently. Alongside the requested permissions, the dialog renders the manifest's `contentAccess[]` (per-table content allowlist, with modes) and `networkAllowedHosts` (outbound-host allowlist), and on upgrade diffs all three against the prior install so new access is impossible to miss.
 
 **One authority, three checkpoints.** The declared `permissions` array (what the
 plugin *asked for*) is used only by the install/consent UI. Enforcement always
diff --git a/src/__tests__/plugins/permissionReviewSection.test.tsx b/src/__tests__/plugins/permissionReviewSection.test.tsx
index 889f6e02d..58f45f52a 100644
--- a/src/__tests__/plugins/permissionReviewSection.test.tsx
+++ b/src/__tests__/plugins/permissionReviewSection.test.tsx
@@ -3,12 +3,16 @@
  *
  * The critical safety invariant is: when a plugin upgrade requests new
  * permissions, the UI must surface them prominently so the site owner
- * can spot a permission expansion before clicking "Update".
+ * can spot a permission expansion before clicking "Update". The same
+ * invariant covers the manifest's `contentAccess[]` allowlist — a new
+ * table, or a new mode on an already-approved table, must show as new.
  */
 import { afterEach, describe, expect, it } from 'bun:test'
 import { cleanup, render, screen } from '@testing-library/react'
 import {
+  OWN_CREATED_CONTENT_TABLE,
   PermissionReviewSection,
+  computeContentAccessDiff,
   computePermissionDiff,
 } from '@plugins/components/PermissionReviewSection'
 import type { PluginManifest, PluginPermission } from '@core/plugin-sdk'
@@ -69,6 +73,71 @@ describe('computePermissionDiff', () => {
   })
 })
 
+describe('computeContentAccessDiff', () => {
+  it('marks every entry new on a fresh install and sorts modes canonically', () => {
+    const rows = computeContentAccessDiff(
+      [{ table: 'posts', modes: ['write', 'read'] }],
+      undefined,
+      false,
+    )
+    expect(rows).toEqual([
+      { table: 'posts', modes: ['read', 'write'], addedModes: [], status: 'new' },
+    ])
+  })
+
+  it('diffs new, existing, and dropped tables on upgrade, new first', () => {
+    const rows = computeContentAccessDiff(
+      [
+        { table: 'pages', modes: ['read'] },
+        { table: 'reviews', modes: ['read', 'write'] },
+      ],
+      [
+        { table: 'pages', modes: ['read'] },
+        { table: 'posts', modes: ['read'] },
+      ],
+      true,
+    )
+    expect(rows.map((r) => [r.table, r.status])).toEqual([
+      ['reviews', 'new'],
+      ['pages', 'existing'],
+      ['posts', 'dropped'],
+    ])
+  })
+
+  it('promotes an already-approved table to new when the update adds modes', () => {
+    const rows = computeContentAccessDiff(
+      [{ table: 'posts', modes: ['read', 'write'] }],
+      [{ table: 'posts', modes: ['read'] }],
+      true,
+    )
+    expect(rows).toEqual([
+      { table: 'posts', modes: ['read', 'write'], addedModes: ['write'], status: 'new' },
+    ])
+  })
+
+  it('keeps a table with reduced modes as existing, showing the requested modes', () => {
+    const rows = computeContentAccessDiff(
+      [{ table: 'posts', modes: ['read'] }],
+      [{ table: 'posts', modes: ['read', 'write'] }],
+      true,
+    )
+    expect(rows).toEqual([
+      { table: 'posts', modes: ['read'], addedModes: [], status: 'existing' },
+    ])
+  })
+
+  it('renders dropped rows with the previously-declared modes', () => {
+    const rows = computeContentAccessDiff(
+      [],
+      [{ table: 'posts', modes: ['delete', 'read'] }],
+      true,
+    )
+    expect(rows).toEqual([
+      { table: 'posts', modes: ['read', 'delete'], addedModes: [], status: 'dropped' },
+    ])
+  })
+})
+
 describe('PermissionReviewSection — fresh install', () => {
   it('shows the review heading + lists every permission with no badges', () => {
     render(
@@ -269,3 +338,125 @@ describe('PermissionReviewSection — upgrade with new permissions', () => {
     expect(droppedRow?.getAttribute('data-permission')).toBe('cms.storage')
   })
 })
+
+describe('PermissionReviewSection — content tables', () => {
+  it('lists each contentAccess entry with its modes on a fresh install', () => {
+    render(
+      <PermissionReviewSection
+        pending={{
+          manifest: {
+            ...baseManifest,
+            permissions: [
+              'cms.content.read',
+              'cms.content.write',
+            ] satisfies PluginPermission[],
+            contentAccess: [
+              { table: 'posts', modes: ['read', 'write'] },
+              { table: 'pages', modes: ['read'] },
+            ],
+          },
+        }}
+        uploading={false}
+        onCancel={() => {}}
+        onConfirm={() => {}}
+      />,
+    )
+    const section = screen.getByTestId('permission-review-content-tables')
+    expect(section.textContent).toContain('Content tables')
+    const rows = Array.from(
+      section.querySelectorAll<HTMLElement>('[data-content-table]'),
+    )
+    expect(rows.map((row) => row.dataset.contentTable)).toEqual(['pages', 'posts'])
+    expect(rows[1].textContent).toContain('posts')
+    expect(rows[1].textContent).toContain('Read, write')
+    // Fresh install shows no diff badges.
+    expect(screen.queryByText('Already approved')).toBeNull()
+  })
+
+  it('omits the section when the manifest declares no contentAccess', () => {
+    render(
+      <PermissionReviewSection
+        pending={{
+          manifest: { ...baseManifest, permissions: ['cms.routes'] },
+        }}
+        uploading={false}
+        onCancel={() => {}}
+        onConfirm={() => {}}
+      />,
+    )
+    expect(screen.queryByTestId('permission-review-content-tables')).toBeNull()
+  })
+
+  it('renders the @own-created marker human-readably', () => {
+    render(
+      <PermissionReviewSection
+        pending={{
+          manifest: {
+            ...baseManifest,
+            permissions: [
+              'cms.content.read',
+              'cms.content.write',
+            ] satisfies PluginPermission[],
+            contentAccess: [
+              { table: OWN_CREATED_CONTENT_TABLE, modes: ['read', 'write'] },
+            ],
+          },
+        }}
+        uploading={false}
+        onCancel={() => {}}
+        onConfirm={() => {}}
+      />,
+    )
+    const section = screen.getByTestId('permission-review-content-tables')
+    expect(section.textContent).toContain('Tables this plugin creates')
+    expect(section.textContent).not.toContain(OWN_CREATED_CONTENT_TABLE)
+  })
+
+  it('badges new tables, added modes, and dropped tables on upgrade', () => {
+    render(
+      <PermissionReviewSection
+        pending={{
+          manifest: {
+            ...baseManifest,
+            permissions: [
+              'cms.content.read',
+              'cms.content.write',
+            ] satisfies PluginPermission[],
+            contentAccess: [
+              // `write` is newly requested on the already-approved table.
+              { table: 'posts', modes: ['read', 'write'] },
+              // Brand-new table.
+              { table: 'reviews', modes: ['read'] },
+            ],
+          },
+          upgradeFromVersion: '1.0.0',
+          previouslyGrantedPermissions: [
+            'cms.content.read',
+            'cms.content.write',
+          ] satisfies PluginPermission[],
+          previousContentAccess: [
+            { table: 'posts', modes: ['read'] },
+            { table: 'legacy', modes: ['read'] },
+          ],
+        }}
+        uploading={false}
+        onCancel={() => {}}
+        onConfirm={() => {}}
+      />,
+    )
+    const section = screen.getByTestId('permission-review-content-tables')
+    const rows = Array.from(
+      section.querySelectorAll<HTMLElement>('[data-content-table]'),
+    )
+    expect(rows.map((row) => [row.dataset.contentTable, row.dataset.status])).toEqual([
+      ['posts', 'new'],
+      ['reviews', 'new'],
+      ['legacy', 'dropped'],
+    ])
+    // The already-approved table that gained a mode calls the mode out.
+    expect(rows[0].textContent).toContain('newly requested: write')
+    // The dropped table shows its previously-declared modes, struck through.
+    expect(rows[2].textContent).toContain('No longer requested')
+    expect(rows[2].textContent).toContain('Read')
+  })
+})
diff --git a/src/admin/pages/plugins/components/PermissionReviewSection/PermissionReviewSection.module.css b/src/admin/pages/plugins/components/PermissionReviewSection/PermissionReviewSection.module.css
index 9949500f7..d5e8e80e2 100644
--- a/src/admin/pages/plugins/components/PermissionReviewSection/PermissionReviewSection.module.css
+++ b/src/admin/pages/plugins/components/PermissionReviewSection/PermissionReviewSection.module.css
@@ -112,7 +112,8 @@
     font-size: var(--text-m);
 }
 
-.row[data-status="dropped"] .label strong {
+.row[data-status="dropped"] .label strong,
+.row[data-status="dropped"] .label code {
     text-decoration: line-through;
 }
 
@@ -153,12 +154,13 @@
 }
 
 /*
- * External-host allowlist section — surfaces `networkAllowedHosts` from
- * the manifest separately from CMS permissions. The two are
+ * Manifest-allowlist sections — surface `contentAccess` (which CMS tables
+ * the plugin can touch, per mode) and `networkAllowedHosts` (which remote
+ * origins it can talk to) separately from CMS permissions. The three are
  * complementary: permissions answer "what CMS surface can the plugin
- * touch?", hosts answer "what remote origins can it talk to?".
+ * touch?", the allowlists answer "which concrete tables and origins?".
  */
-.networkSection {
+.allowlistSection {
     display: flex;
     flex-direction: column;
     gap: var(--space-s);
@@ -166,13 +168,13 @@
     border-top: 1px solid var(--border);
 }
 
-.networkHeader {
+.allowlistHeader {
     display: flex;
     flex-direction: column;
     gap: var(--space-4xs);
 }
 
-.networkHeader strong {
+.allowlistHeader strong {
     color: var(--text-bright);
     font-size: var(--text-m);
     font-weight: 600;
diff --git a/src/admin/pages/plugins/components/PermissionReviewSection/PermissionReviewSection.tsx b/src/admin/pages/plugins/components/PermissionReviewSection/PermissionReviewSection.tsx
index 754bb33e6..25bc23a3b 100644
--- a/src/admin/pages/plugins/components/PermissionReviewSection/PermissionReviewSection.tsx
+++ b/src/admin/pages/plugins/components/PermissionReviewSection/PermissionReviewSection.tsx
@@ -20,18 +20,28 @@
  * banner ("No new permissions in this update") so the user can confirm
  * with confidence.
  *
- * Also displays `networkAllowedHosts` from the manifest in its own section.
- * Permissions describe broad CMS capabilities ("inject scripts"); the
- * host list describes the concrete remote origins those scripts will talk
- * to (e.g. `threejs.org`, `*.cdn.example.com`). Both dimensions are
- * security-relevant: a plugin with `frontend.assets` plus an unexpected
- * allowlist entry can exfiltrate visitor data to that host. Showing both
- * before activation is the only way the operator can make an informed
- * decision.
+ * Also displays the manifest's two allowlists, each in its own section:
+ *
+ *   • `networkAllowedHosts` — the concrete remote origins the plugin's
+ *     code will talk to (e.g. `threejs.org`, `*.cdn.example.com`).
+ *   • `contentAccess` — the CMS tables whose entries the plugin can touch,
+ *     with per-table modes. The `@own-created` marker renders as the
+ *     human-readable "Tables this plugin creates".
+ *
+ * Permissions describe broad CMS capabilities ("inject scripts", "write
+ * content"); the allowlists describe the concrete origins and tables those
+ * capabilities apply to. All three dimensions are security-relevant: a
+ * plugin with `frontend.assets` plus an unexpected host entry can
+ * exfiltrate visitor data, and an upgrade adding `write` mode on an
+ * already-approved table is a silent privilege expansion. Each section
+ * diffs new/existing/dropped rows on upgrade so nothing slips in
+ * unreviewed.
  */
 import { Button } from '@ui/components/Button'
 import {
   permissionDescription,
+  type ContentAccessEntry,
+  type ContentAccessMode,
   type PluginManifest,
   type PluginPermission,
 } from '@core/plugin-sdk'
@@ -41,6 +51,10 @@ import {
   type PermissionDiffRow,
   type PermissionDiffStatus,
 } from './computePermissionDiff'
+import {
+  computeContentAccessDiff,
+  isOwnCreatedContentTable,
+} from './computeContentAccessDiff'
 import styles from './PermissionReviewSection.module.css'
 
 interface PermissionReviewPending {
@@ -54,6 +68,12 @@ interface PermissionReviewPending {
    * exactly the kind of supply-chain attack the consent screen should catch.
    */
   previousNetworkAllowedHosts?: string[]
+  /**
+   * The previously-installed manifest's `contentAccess` allowlist (when this
+   * is an upgrade). Used to flag tables — and modes on already-approved
+   * tables — that the upgrade adds, the same way hosts are diffed above.
+   */
+  previousContentAccess?: ContentAccessEntry[]
 }
 
 type HostDiffStatus = 'new' | 'existing' | 'dropped'
@@ -105,6 +125,12 @@ function statusBadgeLabel(status: PermissionDiffStatus): string {
   return 'No longer requested'
 }
 
+/** "read, write" → "Read, write" — modes stay lowercase manifest literals. */
+function formatContentAccessModes(modes: readonly ContentAccessMode[]): string {
+  const joined = modes.join(', ')
+  return joined.charAt(0).toUpperCase() + joined.slice(1)
+}
+
 export function PermissionReviewSection({
   pending,
   uploading,
@@ -134,6 +160,17 @@ export function PermissionReviewSection({
   const hasAppPages = pending.manifest.adminPages.some((page) => page.content.kind === 'app')
   const hasEditorEntrypoint = Boolean(pending.manifest.entrypoints?.editor)
 
+  const contentAccessRows = computeContentAccessDiff(
+    pending.manifest.contentAccess ?? [],
+    pending.previousContentAccess,
+    isUpgrade,
+  )
+  const hostRows = diffNetworkAllowedHosts(
+    pending.manifest.networkAllowedHosts ?? [],
+    pending.previousNetworkAllowedHosts,
+    isUpgrade,
+  )
+
   return (
     <section
       className={styles.review}
@@ -220,47 +257,83 @@ export function PermissionReviewSection({
         </ul>
       )}
 
-      {(() => {
-        const hostRows = diffNetworkAllowedHosts(
-          pending.manifest.networkAllowedHosts ?? [],
-          pending.previousNetworkAllowedHosts,
-          isUpgrade,
-        )
-        if (hostRows.length === 0) return null
-        return (
-          <div
-            className={styles.networkSection}
-            data-testid="permission-review-network-hosts"
-          >
-            <div className={styles.networkHeader}>
-              <strong>External hosts</strong>
-              <span className={styles.description}>
-                The plugin will connect to these hosts from the server and
-                from published pages. Hosts not listed here are blocked.
-              </span>
-            </div>
-            <ul className={styles.list}>
-              {hostRows.map((row) => (
-                <li
-                  key={`${row.host}:${row.status}`}
-                  className={styles.row}
-                  data-status={row.status}
-                  data-network-host={row.host}
-                >
-                  <div className={styles.label}>
-                    <code>{row.host}</code>
-                    {isUpgrade && (
-                      <span className={`${styles.badge} ${statusBadgeClass(row.status)}`}>
-                        {statusBadgeLabel(row.status)}
-                      </span>
-                    )}
-                  </div>
-                </li>
-              ))}
-            </ul>
+      {contentAccessRows.length > 0 && (
+        <div
+          className={styles.allowlistSection}
+          data-testid="permission-review-content-tables"
+        >
+          <div className={styles.allowlistHeader}>
+            <strong>Content tables</strong>
+            <span className={styles.description}>
+              The plugin's access to CMS content is limited to these tables
+              and modes. Tables not listed here are blocked.
+            </span>
           </div>
-        )
-      })()}
+          <ul className={styles.list}>
+            {contentAccessRows.map((row) => (
+              <li
+                key={`${row.table}:${row.status}`}
+                className={styles.row}
+                data-status={row.status}
+                data-content-table={row.table}
+              >
+                <div className={styles.label}>
+                  {isOwnCreatedContentTable(row.table) ? (
+                    <strong>Tables this plugin creates</strong>
+                  ) : (
+                    <code>{row.table}</code>
+                  )}
+                  {isUpgrade && (
+                    <span className={`${styles.badge} ${statusBadgeClass(row.status)}`}>
+                      {statusBadgeLabel(row.status)}
+                    </span>
+                  )}
+                </div>
+                <span className={styles.description}>
+                  {formatContentAccessModes(row.modes)}
+                  {isUpgrade && row.addedModes.length > 0 && (
+                    <> — newly requested: {row.addedModes.join(', ')}</>
+                  )}
+                </span>
+              </li>
+            ))}
+          </ul>
+        </div>
+      )}
+
+      {hostRows.length > 0 && (
+        <div
+          className={styles.allowlistSection}
+          data-testid="permission-review-network-hosts"
+        >
+          <div className={styles.allowlistHeader}>
+            <strong>External hosts</strong>
+            <span className={styles.description}>
+              The plugin will connect to these hosts from the server and
+              from published pages. Hosts not listed here are blocked.
+            </span>
+          </div>
+          <ul className={styles.list}>
+            {hostRows.map((row) => (
+              <li
+                key={`${row.host}:${row.status}`}
+                className={styles.row}
+                data-status={row.status}
+                data-network-host={row.host}
+              >
+                <div className={styles.label}>
+                  <code>{row.host}</code>
+                  {isUpgrade && (
+                    <span className={`${styles.badge} ${statusBadgeClass(row.status)}`}>
+                      {statusBadgeLabel(row.status)}
+                    </span>
+                  )}
+                </div>
+              </li>
+            ))}
+          </ul>
+        </div>
+      )}
 
       <div className={styles.actions}>
         <Button
diff --git a/src/admin/pages/plugins/components/PermissionReviewSection/computeContentAccessDiff.ts b/src/admin/pages/plugins/components/PermissionReviewSection/computeContentAccessDiff.ts
new file mode 100644
index 000000000..c4f7331d5
--- /dev/null
+++ b/src/admin/pages/plugins/components/PermissionReviewSection/computeContentAccessDiff.ts
@@ -0,0 +1,112 @@
+/**
+ * Pure helper that diffs the new manifest's `contentAccess[]` allowlist
+ * against the previously-installed manifest's on an upgrade. Lives in its
+ * own file (like `computePermissionDiff`) so the `.tsx` component file
+ * stays Fast-Refresh-friendly.
+ *
+ * Rows are keyed by table:
+ *
+ *   • `new`      — table not previously declared, OR previously declared
+ *                  but the update requests modes the operator never
+ *                  approved for it (`addedModes` lists them). Both are
+ *                  access the operator has not yet consented to.
+ *   • `existing` — table previously declared with no new modes (a shrunk
+ *                  mode set still counts as existing — the row shows
+ *                  exactly what the new manifest requests).
+ *   • `dropped`  — table previously declared but absent from the new
+ *                  manifest; the row shows the previously-declared modes.
+ *
+ * Order of rows: new first (most important to surface), existing second,
+ * dropped last — same ordering the permission and host diffs use.
+ */
+import type { ContentAccessEntry, ContentAccessMode } from '@core/plugin-sdk'
+
+/**
+ * Marker value in `contentAccess[].table` that stands for "every table this
+ * plugin itself creates at runtime" instead of a concrete table slug. The
+ * consent screen renders it as a human-readable phrase ("Tables this plugin
+ * creates") rather than a literal slug.
+ */
+export const OWN_CREATED_CONTENT_TABLE = '@own-created'
+
+export function isOwnCreatedContentTable(table: string): boolean {
+  return table === OWN_CREATED_CONTENT_TABLE
+}
+
+export type ContentAccessDiffStatus = 'new' | 'existing' | 'dropped'
+
+export interface ContentAccessDiffRow {
+  table: string
+  /**
+   * Modes the row displays, in canonical read → write → publish → delete
+   * order: the requested modes for `new` / `existing` rows, the
+   * previously-declared modes for `dropped` rows.
+   */
+  modes: ContentAccessMode[]
+  /**
+   * Upgrade only: modes newly requested on a table the operator already
+   * approved. Non-empty exactly when an already-approved table was promoted
+   * to `new` — a brand-new table row keeps this empty because the whole row
+   * is new access.
+   */
+  addedModes: ContentAccessMode[]
+  status: ContentAccessDiffStatus
+}
+
+const MODE_ORDER: Record<ContentAccessMode, number> = {
+  read: 0,
+  write: 1,
+  publish: 2,
+  delete: 3,
+}
+
+function sortModes(modes: readonly ContentAccessMode[]): ContentAccessMode[] {
+  return [...modes].sort((a, b) => MODE_ORDER[a] - MODE_ORDER[b])
+}
+
+export function computeContentAccessDiff(
+  next: readonly ContentAccessEntry[],
+  previous: readonly ContentAccessEntry[] | undefined,
+  isUpgrade: boolean,
+): ContentAccessDiffRow[] {
+  const previousByTable = new Map((previous ?? []).map((entry) => [entry.table, entry]))
+  const nextTables = new Set(next.map((entry) => entry.table))
+
+  const rows: ContentAccessDiffRow[] = []
+  for (const entry of next) {
+    const prior = isUpgrade ? previousByTable.get(entry.table) : undefined
+    if (!prior) {
+      rows.push({
+        table: entry.table,
+        modes: sortModes(entry.modes),
+        addedModes: [],
+        status: 'new',
+      })
+      continue
+    }
+    const priorModes = new Set(prior.modes)
+    const addedModes = sortModes(entry.modes.filter((mode) => !priorModes.has(mode)))
+    rows.push({
+      table: entry.table,
+      modes: sortModes(entry.modes),
+      addedModes,
+      status: addedModes.length > 0 ? 'new' : 'existing',
+    })
+  }
+  if (isUpgrade) {
+    for (const entry of previous ?? []) {
+      if (!nextTables.has(entry.table)) {
+        rows.push({
+          table: entry.table,
+          modes: sortModes(entry.modes),
+          addedModes: [],
+          status: 'dropped',
+        })
+      }
+    }
+  }
+  const order: Record<ContentAccessDiffStatus, number> = { new: 0, existing: 1, dropped: 2 }
+  return rows.sort(
+    (a, b) => order[a.status] - order[b.status] || a.table.localeCompare(b.table),
+  )
+}
diff --git a/src/admin/pages/plugins/components/PermissionReviewSection/index.ts b/src/admin/pages/plugins/components/PermissionReviewSection/index.ts
index 74e744e95..d23745cc0 100644
--- a/src/admin/pages/plugins/components/PermissionReviewSection/index.ts
+++ b/src/admin/pages/plugins/components/PermissionReviewSection/index.ts
@@ -2,3 +2,8 @@ export { PermissionReviewSection } from './PermissionReviewSection'
 export {
   computePermissionDiff,
 } from './computePermissionDiff'
+export {
+  computeContentAccessDiff,
+  isOwnCreatedContentTable,
+  OWN_CREATED_CONTENT_TABLE,
+} from './computeContentAccessDiff'
diff --git a/src/admin/pages/plugins/hooks/usePluginsWorkspace.ts b/src/admin/pages/plugins/hooks/usePluginsWorkspace.ts
index e22d75cba..345eed440 100644
--- a/src/admin/pages/plugins/hooks/usePluginsWorkspace.ts
+++ b/src/admin/pages/plugins/hooks/usePluginsWorkspace.ts
@@ -18,6 +18,7 @@ import {
 } from '@core/plugins/manifest'
 import type {
   CmsPluginsPayload,
+  ContentAccessEntry,
   InstalledPlugin,
   PluginManifest,
   PluginPermission,
@@ -61,6 +62,13 @@ interface PendingInstall {
    * value so an upgrade adding new external hosts shows them as "New".
    */
   previousNetworkAllowedHosts?: string[]
+  /**
+   * `contentAccess` from the manifest of the existing install (when this is
+   * an upgrade). The dialog diffs it against the new manifest's value so an
+   * upgrade adding tables — or new modes on already-approved tables — shows
+   * them as "New".
+   */
+  previousContentAccess?: ContentAccessEntry[]
 }
 
 /**
@@ -312,6 +320,7 @@ export function usePluginsWorkspace(): PluginsWorkspaceVM {
         ? existing.grantedPermissions
         : undefined
       const previousNetworkAllowedHosts = existing?.manifest.networkAllowedHosts
+      const previousContentAccess = existing?.manifest.contentAccess
 
       // EVERY install and upgrade goes through the review dialog — including
       // a zero-permission declarative plugin, which renders "No permissions
@@ -325,6 +334,7 @@ export function usePluginsWorkspace(): PluginsWorkspaceVM {
         ...(previousNetworkAllowedHosts !== undefined
           ? { previousNetworkAllowedHosts }
           : {}),
+        ...(previousContentAccess !== undefined ? { previousContentAccess } : {}),
       })
     } catch (err) {
       setError(getErrorMessage(err, 'Could not install plugin'))
diff --git a/src/core/plugin-sdk/types/manifest.ts b/src/core/plugin-sdk/types/manifest.ts
index a20e1a660..b5a34beec 100644
--- a/src/core/plugin-sdk/types/manifest.ts
+++ b/src/core/plugin-sdk/types/manifest.ts
@@ -88,9 +88,13 @@ export interface PluginManifest {
   networkAllowedHosts?: string[]
   /**
    * Per-table allowlist for the `api.cms.content.*` surface. Required when
-   * ANY of the `cms.content.*` permissions are granted. The install consent
-   * screen renders this verbatim so the operator approves the exact set of
-   * tables the plugin can touch before granting the permission.
+   * ANY of the `cms.content.*` permissions are granted. The install/upgrade
+   * consent screen renders every entry with its modes in a "Content tables"
+   * section (the `@own-created` marker as "Tables this plugin creates") and,
+   * on upgrade, diffs new / already-approved / no-longer-requested entries —
+   * a mode added to an already-approved table is flagged as new access — so
+   * the operator approves the exact set of tables the plugin can touch
+   * before granting the permission.
    *
    * Modes are checked AGAINST the granted permissions at install time: a
    * `mode: "publish"` entry requires `cms.content.publish`, etc. — and the