Approval is not a forever verdict.

1. Separate intent from observation

An approved list records what an organization intends to allow. Discovery records what a bounded inspection actually observed. These are related but different datasets, and the difference is where review work begins.

2. Build a structural baseline

A useful baseline should be specific enough to compare and restrained enough to avoid collecting secrets. It can identify the server, transport, safe executable identity, selected tool or permission structure and provenance without storing token values, header values or unnecessary full local paths.

• Identity: Record the logical server identity and the source that produced the observation.
• Transport: Distinguish local stdio configuration from remote endpoint structure.
• Execution: Preserve a safe command basename and bounded structural signals, not argument or environment values.
• Scope: Capture relevant permission or tool-shape changes without treating capability alone as runtime behavior.
• Provenance: Keep client, project and configuration context so a reviewer can reproduce the observation.

3. Make review states explicit

Governance becomes easier to operate when the report says what happened without collapsing every state into a risk score. A current structure can match an approved baseline, require review, or represent an approved item that is no longer observed.

4. Use a review loop, not a one-time checkbox

1. Discover: collect evidence from supported, documented surfaces.
2. Normalize: merge duplicate observations while retaining provenance.
3. Review: examine owner, source, transport, command identity, permissions and tool changes.
4. Approve: record the exact structural state that was reviewed.
5. Compare: run the same bounded inspection later and classify changes.
6. Gate where needed: use a machine-readable review result in CI when an unapproved change should stop a workflow.

Approval should mean “matches the reviewed structural baseline,” not “safe forever.”

5. Know what drift detection cannot prove

A structural comparison is valuable because it is explainable, but it is not runtime monitoring. It cannot prove that a server is safe, that a connection is active, or that no unobserved client, platform or network connection exists.

• A repository or package can change after inspection.
• Runtime behavior can differ from static configuration evidence.
• Unsupported clients and locations remain outside the bounded observation.
• Authorization, deployment context and operational controls need separate review.

6. Start with a read-only control

For an early MCP governance program, a read-only inventory and drift report can create value before enforcement. It gives security and platform teams a shared evidence record, lets developers understand why a review is required and avoids breaking production workflows while coverage is still being validated.

ShadowMCP’s current direction is deliberately bounded: discover, inventory, explain and govern. The public repository scanner is a separate pre-execution evidence path; it does not execute repository code or issue a safe/unsafe verdict.

Sources and further reading

This page describes an operational model and the current bounded semantics of ShadowMCP. For broader security controls, use the security guide and checklist below.

• ShadowMCP MCP security guide
• MCP server security checklist
• Shadow MCP discovery and inventory
• OWASP — MCP Security Cheat Sheet
• Model Context Protocol — Security Best Practices