Notifications
Clear all
Topic starter
18/08/2026 2:35 pm
TL;DR: Deterministic validation and sandboxed execution still mattered, even as MCP tooling added cost and context overhead by encoding workflows the model could already execute through simpler skills and shell access, according to TENZIR. The broader lesson is that MCP should expose external capabilities, not preserve brittle orchestration layers that age faster than the models they serve.
NHIMG editorial — based on content published by TENZIR: the article on rethinking MCP workflows and tool overhead
By the numbers:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
Questions worth separating out
Q: How should teams scope permissions for AI tools and MCP connectors?
A: Treat every connector, plugin, or orchestration service as a separate non-human identity with its own authorization boundary.
Q: Why do AI-assisted response workflows create new governance risk?
A: They compress the time between detection and action, which reduces the window for human review and increases the impact of a bad decision.
Q: What do security teams get wrong about AI orchestration tools?
A: They often assume more structure equals more safety.
Practitioner guidance
- Inventory MCP tools by actual control value Classify each tool as either a real capability boundary or a thin wrapper around shell, read, write, or documentation access.
- Separate workflow knowledge from tool privilege Move step-by-step instructions into documentation that models can search, and keep privileged execution in narrowly scoped services with explicit authorization.
- Apply least privilege to AI tool identities Treat each MCP connector, plugin, or orchestration service as an identity with its own permission set, logging, and review cycle.
What's in the full article
TENZIR's full blog post covers the operational detail this post intentionally leaves for the source:
- A line-by-line breakdown of the Tenzir Claude Marketplace experiment, including the exact tool-call counts and cost comparison.
- The specific MCP tools the vendor says it will deprecate, including workflow orchestration and documentation wrappers.
- Implementation detail on which capabilities remain in the MCP server, such as sandboxed execution, schema validation, and live system queries.
- The vendor's internal reasoning for separating portable skills from connected infrastructure in different deployment models.
👉 Read TENZIR's analysis of when MCP adds control value and when it adds overhead →
MCP workflow overhead: are your controls matching model capability?
Explore further
18/08/2026 3:21 pm
MCP governance debt is becoming a real identity problem. When teams wrap simple actions in custom tools, they are not just increasing maintenance overhead, they are creating a larger delegated identity surface. Every extra tool call becomes another place where authentication, authorization, and auditability can fail. That means the real question is not whether MCP works, but whether the protocol is being used to expose capabilities or to camouflage unnecessary privilege.
A question worth separating out:
Q: How should organisations decide whether to keep an MCP tool or remove it?
A: Keep the tool only if it provides sandboxing, deterministic validation, authenticated access to a live system, or another capability the model cannot safely replicate. Remove it if it merely sequences commands, fetches docs, or wraps a terminal operation. That decision should be based on control value, not habit or legacy workflow design.
👉 Read our full editorial: MCP workflows are overfitting AI models to rigid tooling
