Should MCP tools ship with lockfiles and capability manifests?

As a Linux security engineer, I’m uneasy with the current meaning of “approve this tool” for MCP servers and similar coding-agent connectors. A tool name is not a capability boundary: the effective reach may also depend on configuration, plugins, environment variables, filesystem scope, commands, and outbound network access. MCP servers are trusted much like installed software, and available tools can change at runtime.

I’d like agent tools to ship with a dependency-style lockfile plus an explicit, ideally signed capability manifest: every readable or writable path, command, network destination, and secret class. Approval should mean approving that snapshot, not a label that can quietly expand later. At the same time, prompting for every routine action would make automation unusable.

Should the ecosystem standardize signed manifests, conservative sandbox defaults, and human-readable diffs whenever permissions change? Developers and security practitioners: what does this look like in your real workflow, and what’s the strongest counterargument?

The lockfile analogy is useful, but I’d separate dependency identity from runtime authority. Pinning a server build does not tell me what a shell wrapper can reach after startup. The manifest needs to describe effective privileges, and the client should fail closed when that description is unavailable or changes unexpectedly.

One important distinction: server cards and descriptive metadata are not the same thing as an access-control contract. I would treat any manifest as review evidence unless the client enforces it cryptographically and operationally. Otherwise we risk creating another reassuring document that does not constrain behavior.

The usability failure mode is real. Most developers will approve a broad manifest once and then ignore the warnings forever. I’d rather see a small number of risk tiers, sensible defaults, and a readable diff only for material changes. Security controls have to fit the moment of work.

Agreed on tiers, with one caveat: “material” cannot mean only new tools. A changed path glob, newly allowed domain, or secret passed through an existing command can be just as important. The diff should show both the declared change and the resulting effective permission.

For local coding, I’d accept a manifest that says “repository tree plus these build commands,” then prompts for anything outside it. Asking me to approve every compiler invocation would be pointless. The default boundary matters more than making the manifest beautiful.

Secrets deserve their own treatment. Listing “environment variables” is not enough if the connector can forward arbitrary values to a network destination. I’d want secret classes, explicit destinations, and a rule that values are never exposed to the model unless the operation requires it.

I’m not convinced signatures solve the central problem. A perfectly signed manifest can authorize too much, and users routinely accept prompts they do not understand. Sandboxing and narrowly scoped policies seem more valuable than proving that the broad request was not modified.

The practical test is revocation and rollback. If a plugin or configuration update expands access, can the client show the diff, refuse startup, and restore the previous approved state? If not, a lockfile is mostly an audit artifact. Useful, but not a control.