Tool parameters must be bounded at execution time (prefix allowlists, typed inputs, write fences).
Every caller should run with scoped identity and scoped credentials, not a shared admin backend.
If you cannot prove what happened after the call, you do not have a control plane, you have a claim.
The useful question is not "does this MCP server work?" It is "what happens when one tool call is compromised?"
The current security findings cluster is concrete: unconstrained string parameters, path traversal in filesystem tools, SSRF in remote connectors, sandbox bypasses, and weak write fences. None of this requires mystical threat modeling. It requires server-side boundaries.
1. Scope is the boundary that matters
The moment you expose a tool that can read arbitrary files, write arbitrary paths, fetch arbitrary URLs, or mutate broad resources, you have already made prompt injection a production incident class. The fix is not a better prompt. The fix is an allowlist.
- Constrain filesystem tools to explicit prefixes and resolve paths safely.
- Constrain network tools to explicit host allowlists, not open URLs.
- Constrain write tools to explicit targets and require typed, schema-validated inputs.
2. Principals must be real
The security posture collapses when every workflow shares one backend credential. A safe server needs scoped identity per caller or per tenant, then scoped credentials that match the smallest intended lane.
If a low-trust research agent can inherit the same authority as a deploy workflow, you do not have a principal model. You have a single shared blast radius. In shared runtimes, that same mistake becomes a multi-tenant containment problem, because one caller can now inherit another tenant's effective authority.
3. Evidence turns policy into control
Production operators need more than logs that say "error". They need structured records that answer who acted, what they attempted, what was denied, and why. Evidence is what makes containment verifiable.
4. Policy language is only useful if the boundary survives runtime
Generated permission manifests, gateway RBAC layers, and governance toolkits are useful because they expose intended boundaries. They are not the boundary itself.
The operator test is still runtime reality: does the wrong caller see fewer tools, get a typed denial instead of a vague failure, and leave evidence of which lane consumed the shared quota or backend authority after the remote hop.
If the manifest reads narrow but discovery still reveals write-capable tools, or a gateway claims RBAC but cannot explain which principal burned the shared budget during a noisy loop, you documented intent without creating control.
Split public or low-trust servers into read-only tools. Do not mix read and write tools behind one handshake.
Read-Only MCP as a Trust Class →Bound file paths, repo targets, URL hosts, and write destinations with explicit allowlisted prefixes at execution time.
Scope Constraints and Blast Radius →Authenticated must not mean every tool. Filter discovery and enforce tool-level authorization per role, tenant, or workflow intent.
Tool-Level Permission Scoping →Capture principal, parameters, tool, policy decision, and outcome. Typed denials must be distinguishable from runtime failures.
MCP Observability →Start with one bounded lane
If the security model is scope plus principals plus evidence, the right next move is not a bigger catalog. Start with a governed capability lane that makes authority visible and keeps scope small.
The security model usually breaks when one careful tool call becomes many unattended ones. These three pages show how scope, principals, and evidence stay honest once loops, shared budgets, and credential drift enter the picture.
Why the first security failure is often hidden inside retries, tool loops, and overnight recovery branches.
What scope control and spend governors look like once shared quota pressure becomes part of the threat model.
Follow the principal model into rotation, revocation, and scoped credential handling before one expired token widens the blast radius.
The live official-server audits are not failing on one abstract checkbox. They are failing where authority leaks into tool scope, parameter shape, and missing post-call evidence. These five pages are the operator playbook for that exact cluster.
Auth, scope constraints, tenant isolation, governors, recovery, and auditability in one operator checklist.
Why remote auth proves who connected, but not which tools and backend credentials should stay in scope.
Where unconstrained params, hidden write paths, and over-broad manifests turn a clean login into real blast radius.
The evidence layer for policy decisions, denied calls, and the exact runtime trail operators need after a security scare.
Where principals, credentials, tool visibility, and session state either hold tenant boundaries or collapse them.
If you want to see where scope, principals, and evidence fail in real integrations, these provider autopsies show how broad capability shape, auth ceremony, and weak recovery turn a plausible security story into operator pain.
Broad CRM surface and weak replay safety show how fast the principal model collapses when capability shape stays too wide.
Useful for auth ceremony, tenant complexity, and why identity alone does not create a governable authority surface.
A cleaner reference for typed failures, narrow auth shape, and what safer agent-facing execution ergonomics actually look like.
Shows how strong platform fundamentals still need explicit budget, versioning, and recovery boundaries before the security model holds in production.