Skip to content

Inventory & add-on policy

See the MCP servers, skills, add-ons, and IDE plugins configured on each device, and block the add-ons you do not allow.

MCP servers and agent add-ons

A device's Inventory tab lists, per harness, the configured MCP server names and the names of skills, plugins, hook events, agents, commands, and rules. Device search matches these names, and exports include them.

The MCP servers table adds connection details: harness, server name, transport, the remote host or the executable's file name, and the OS account when the privileged service reports it.

Configured is not connected
Inventory shows what is configured in user-scoped locations Sentinel knows about. It does not establish that anything was enabled, connected, running, approved, or used.

Sentinel reads the known configuration files of each harness, for example Claude Code, Codex, Gemini CLI, OpenCode, Cursor, Goose, Continue, and VS Code. It does not follow project paths found in those files, and it does not scan separate project .mcp.json files, custom environment paths, or process environments.

Shown asMeaning
Not reportedThe collector did not report this field: it is older, or the configuration was malformed or too large to read completely.
None detectedThe configuration was inspected and was empty.

Sentinel reports an incomplete scan as not reported instead of presenting a truncated list as complete.

What is and is not uploaded

  • Uploaded: names, and for MCP connections the transport and remote host or executable file name.
  • Never uploaded: configuration values, credentials, arguments, environment values, headers, URL paths and query strings, hook commands, descriptions, configuration paths, skill bodies, and add-on code.

Add-on policy

Open Add-on policy on the device's Inventory tab. Anyone who can view Sentinel can inspect the policy and its reported results; changing it needs sentinel:write. A policy holds up to 128 block rules, each with a harness, a kind (skill, plugin, hook, agent, command, rule, or *), and a name. Harness and name support * and ? wildcards and are case-sensitive.

json
1{
2 "mode": "enforce",
3 "rules": [
4 { "harness": "claude", "kind": "skill", "name": "untrusted-*" }
5 ]
6}
ModeBehavior
MonitorReports what would be blocked, and restores earlier quarantines when safe. New devices start here with no rules.
EnforceMoves matching skill directories and standalone add-on files or directories into a private local quarantine.
DisabledRestores quarantined entries when their original location is free. Removing the matching rule does the same.
Limits of add-on policy
  • Applied by per-user collectors only. Privileged-service devices show Not reported for add-on enforcement.
  • Entries embedded in shared configuration, such as Claude hook events and plugin registries, are reported as unsupported and left intact.
  • IDE plugins are inventoried and classified, not quarantined.
  • Code that is already loaded may stay active until the harness restarts.
  • A user who can modify their own collector or its state can bypass it. It is not a process sandbox.

The console distinguishes a saved policy, a policy awaiting application, and what the device reports after applying it. Policy changes, including disabling enforcement, take effect at the device's next successful heartbeat. An offline device keeps applying the last valid policy.

How quarantine works

Quarantined items stay on the device, in Sentinel's private state directory. Sentinel never overwrites an original when restoring. If the add-on was reinstalled at its original location, the restore reports a conflict and keeps the quarantined copy until you resolve it locally. Up to 256 quarantined items are tracked per device, and paths and file contents are never uploaded.

Before uninstalling a collector or changing its state directory, home, or endpoint, set the policy to Disabled and wait for a successful restoration report. Uninstalling does not restore quarantined items automatically; keep the state directory if you need to recover them.

IDE plugins

Sentinel lists the plugins installed in supported IDEs, ordinary ones as well as agents. It reads local plugin metadata only and never runs IDE commands. Plugin code, settings, and manifest contents are not uploaded.

IDE familyCovered
VS Code familyVS Code and Insiders, Cursor, Windsurf, VSCodium, Trae
JetBrainsIntelliJ IDEA, PyCharm, WebStorm, GoLand, CLion, Rider, RubyMine, PhpStorm, DataGrip, RustRover, Android Studio
ZedInstalled extensions

Multiple versions or profiles of the same IDE are combined into one entry per plugin, so the reported version is not proof of the version currently enabled. Custom, portable, remote, and application-bundled plugin locations are not scanned.

Classify a plugin as an agent

The console labels plugins from a known catalog as agents, including Claude Code, Codex, Copilot, Continue, Cline, Roo Code, and Amazon Q for VS Code, and Copilot, JetBrains AI Assistant, Junie, Windsurf, and Continue for JetBrains. These show Automatic. Unknown plugins default to Not agent. The label is a best-effort capability hint, not evidence that a plugin is enabled or in use.

With sentinel:write, open Classify and choose Agent, Not agent, or Automatic. An override applies to that plugin across every device in the workspace and across all variants of the IDE family, and is marked Admin override. Choosing Automatic removes it.