Designing a Least-Privilege Permission Manifest

An MCP inventory says which tools exist and who owns them. It says nothing about who is allowed to call which one, under what constraint. Write that down separately, as a permission manifest that can be reviewed independently of the agent’s prompts. A single over-broad tool permission can collapse containment controls, turning a narrowly-scoped assistant into a cross-tenant actor that can read or write more than intended, even when the prompts look harmless.

Setting design inputs and defining the manifest boundary

Draw on three inputs that already exist in the integration package. The MCP tool inventory supplies the enumerated tool names and their deterministic contracts: parameters, outputs, known failure modes. The containment envelope contributes its own assumption, that every tool call must be authorized at execution time with least privilege and explicit tenant boundaries representing business units.

Write the permission manifest as a reviewer-facing contract that maps each tool to a set of allowed operations, scopes, and tenant constraints per role. It must answer, in a form a reviewer can approve or reject, which role can invoke which tool, against which tenant, on which data, under which constraints, with what audit evidence. It is not a prompt, not a code snippet, and not a generic identity and access management policy dump. Keep it vendor-neutral and stable across implementation choices, while concrete enough to produce testable expectations later. ...