# Decision: narrow plugin permissions to host authorities

Plugin/Feature permission should mean user-approved host authority, not every contribution the feature declares.

Purpose:

- Explain to the user what dangerous host authority a plugin receives.
- Ensure sandboxed/external plugin code is not given APIs or handles for unapproved actions.
- Keep registry contribution integrity separate from authority grants.

Revised model:

- Contributions are descriptor/digest-locked declarations:
  - Tools
  - Hooks
  - BackgroundTasks
  - Service providers
- Host authorities are user-approved sandbox/object-capability grants:
  - filesystem access
  - network access
  - secret refs
  - model-visible durable notification/history append
  - Pod management façade access where exposed
  - store/state access such as Memory/WorkItem or persistent plugin state where applicable

Tool/Hook/BackgroundTask/ServiceProvider declarations should be shown during install and locked by plugin descriptor/package digest. If they change, the plugin requires re-approval. They do not need separate `ContributeTool`, `ContributeHook`, `RunBackgroundTask`, or `ProvideService` authority variants.

Service consumption is also not a blanket authority by itself. A service requirement is resolved by the host; the authority question depends on what host authority the service handle exposes. Service handles should be narrowed or authority-bound so acquiring one broad service handle cannot become an authority escalation path.

Tool execution remains governed by the existing per-call tool permission / PreToolCall path. Feature authority grants do not replace manifest/tool permissions.