Skip to content

Restore secure MCP execution and bundled pack recovery - #653

Merged
geoffmcc merged 2 commits into
mainfrom
codex/restore-secure-agent-usability
Oct 22, 2026
Merged

geoffmcc merged 2 commits into
mainfrom
codex/restore-secure-agent-usability

Conversation

@geoffmcc

Copy link
Copy Markdown
Owner

Summary

Sidekick's tightened authorization made ordinary MCP client execution hard to bootstrap: a service credential scoped only for pack viewing and management could not authorize standard tool execution. Separately, an upgrade had left bundled Jellyfin compatibility modules with stale provenance, while the security checks correctly refused to load them.

This change restores the intended workflows without weakening the security boundary.

Changes

  • Update the Dashboard's MCP client setup to create a separate, named service principal for each client and let an Owner explicitly choose its scopes.
  • Include standard tools.execute as the default scope; keep pack read/manage permissions optional and separately granted.
  • Preserve credential rotation and one-time token display, and clarify how to configure a generic MCP client with bearer authentication.
  • At MCP Core startup, repair module provenance only for modules owned by a verified first-party bundled pack when the installed version and package digest exactly match the bundled release.
  • Keep the repair idempotent and preserve pack configuration and disabled state. Do not promote third-party packs or mismatched packages.
  • Document the credential scope and bundled module recovery behavior.
  • Add regression coverage for provenance repair boundaries and MCP execution authorization with a scoped service principal.

Security properties

  • Client identities remain explicit service principals; scopes are selected by an Owner.
  • Pack-management authority is not required for ordinary tool execution and is not granted implicitly.
  • Provenance repair uses the verified bundled package lifecycle and exact package hash; it does not disable module isolation or loosen validation.
  • Third-party packs, mismatched versions, and mismatched hashes are not repaired or promoted.
  • Production deployment remains through the guarded origin/main deployment path after merge.

Verification

Passed on this branch:

  • node --check static/dashboard.js
  • node --check src/packs/bundled.js
  • node --check src/index.js
  • node --test test/security-dashboard-service-credentials.test.js test/jellyfin-lifecycle.test.js - 8 tests passed
  • npm run test:packs - 41 tests passed
  • npm run test:dashboard - 63 tests passed
  • npm run check:tests
  • npm run check:docs
  • git diff --check

Deployment

After merge, deploy from a clean main checkout using the documented deployment procedure. Verify the deployed commit and service health afterward.

@geoffmcc
geoffmcc merged commit 1828cec into main Oct 22, 2026
28 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant