A developer copies an MCP configuration containing npx. The editor launches the server when it needs the tool. Nothing appears in the organization's normal software installation process.
When an advisory arrives, a package list may answer the wrong question. It shows what is installed conventionally, while the responder needs to know what actually ran.
Build one useful record
Here is an illustrative record for a fictional integration. The values are examples, not measurements from a real fleet:
tool: reporting-mcp
owner: data-platform
declared_source: registry-package
resolved_version: "<observed-version>"
artifact_digest: "<observed-digest>"
started_by: editor-agent
transport: stdio
capabilities:
- read_reports
credential_scope: reporting-read
last_seen: "<observation-time>"
review_state: needs-review
The distinction between declared and resolved information matters. A configuration may request a floating version while the package runner executes a cached artifact. Record the actual executable or image and the evidence supporting its identity.
Add host, user, startup arguments, working directory, accessible paths, and outbound destinations when relevant. Keep secrets out of the inventory itself; store references and scopes.
Find the record in pieces
Configuration reveals intent. Process observations show what launched. Package caches and lockfiles help identify the artifact. MCP handshakes expose the advertised tools. Network telemetry reveals reachable services and observed destinations.
Correlate these signals rather than treating any one of them as complete. A remote server may update its tool descriptions without a local package change. A stopped process may leave configuration that launches again the next time an editor opens.
Agent skills, prompts, and remote definitions also belong in the record when they influence behavior. Capture their origin and revision where possible.
Answer an advisory with the inventory
When a new advisory names a component, use the record to ask:
- Which observed artifacts match the affected package or version?
- Is the vulnerable feature enabled in those deployments?
- Which callers can reach it?
- What credentials and data are available to the process?
- Which owner can upgrade, disable, or contain it?
That sequence turns a package match into an actionable deployment decision.
Expire evidence honestly
An observation from last month is not proof of what is running now. Retain its timestamp and distinguish running, configured, dormant, removed, and unknown states.
After remediation, observe the new process or artifact. This is the final step in patch prioritization: proving that the running environment changed, rather than only its declared dependency.