MCP workflows are overfitting AI models to rigid tooling

At a glance

What this is: This is an analysis of where MCP server design stops adding value and starts duplicating capabilities the model can already perform through simpler interfaces.

Why it matters: It matters because identity and access teams increasingly need to govern AI systems as tool-using entities, and unnecessary orchestration can hide privilege, audit, and control boundaries.

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.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• 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.

👉 Read TENZIR's analysis of when MCP adds control value and when it adds overhead

Context

MCP, or Model Context Protocol, is becoming one of the main ways enterprises connect AI systems to tools and data. The governance problem is that teams often treat every connector, wrapper, and orchestration layer as if it adds security value, when some layers merely duplicate what the model can do more directly.

This article argues that the control boundary matters more than the number of custom tools. For IAM and NHI teams, that means separating workflow convenience from real privilege, access scoping, and auditability so AI systems do not inherit unnecessary tool authority.

The article’s starting position is increasingly typical in fast-moving AI programmes: many organisations build first around structure and only later discover where the model already had enough capability to operate safely and efficiently.

Key questions

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. Grant only the minimum actions required for the task, log every invocation, and review tool permissions on the same cadence as other privileged accounts. If a tool only wraps a basic command, it usually does not deserve separate standing privilege.

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. The risk grows when the AI can mutate case state or trigger containment automatically, because one mistaken prompt can cascade into several downstream actions before a person intervenes.

Q: What do security teams get wrong about AI orchestration tools?

A: They often assume more structure equals more safety. In practice, some orchestration tools only duplicate what a model can already do through standard interfaces, while adding context overhead and extra places for privilege to leak. The better test is whether the tool enforces a boundary that cannot be achieved through simpler, auditable controls.

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.

Technical breakdown

Why MCP orchestration can become unnecessary context bloat

MCP is designed to let an AI model call external tools through structured interfaces, but every extra wrapper adds schema, metadata, and repeated context consumption. When a tool simply proxies a shell command or documentation lookup, it increases latency and token use without improving the underlying control boundary. The security issue is not just cost. More indirection creates more places where permissions, prompts, and execution paths can drift apart. In identity terms, the system ends up with a larger surface of delegated capability than the task actually requires.

Practical implication: remove MCP tools that only restate basic shell, read, or write operations and keep access boundaries as small as possible.

Which MCP capabilities are genuinely control-relevant

Some MCP functions do add distinct value because they connect the model to stateful infrastructure the model cannot safely improvise, such as sandboxed execution, live system queries, deterministic validation, and long-running orchestration. Those capabilities are not just convenience layers. They are control points where policy, logging, and validation can be enforced outside the model. For NHI governance, these are the places where identity, authentication, and authorization matter most because the model is crossing from reasoning into execution against real systems.

Practical implication: preserve MCP only where it enforces a real boundary, such as sandboxed execution or validated access to live systems.

Why documentation should replace workflow encoding

The article’s strongest technical point is that workflow knowledge does not need to live inside every tool call. If documentation is searchable and accurate, the model can sequence tasks itself instead of relying on rigid step-by-step guides embedded in a protocol layer. That shifts the control model from pre-scripted orchestration to governed capability exposure. For AI security, this is important because fewer hard-coded workflow steps means fewer brittle assumptions about how the model must act, and fewer hidden policy gaps when the model changes behaviour.

Practical implication: treat documentation as the instruction layer and reserve MCP for capabilities that require authenticated access to external systems.

Threat narrative

Attacker objective: The objective would be to exploit over-delegated AI tool access to reach systems, data, or credentials beyond the task scope.

1. Entry occurs when an AI system gains access to too many tools through over-structured MCP wrappers that expose more capability than the task needs.
2. Escalation happens when delegated tool use expands from one-off execution into broad access across documentation, pipelines, and validation paths.
3. Impact is the accumulation of unnecessary attack surface, higher cost, and weaker governance over what the AI can actually do.

NHI Mgmt Group analysis

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.

Tool overfitting is a named governance gap, not just an engineering inefficiency. The article shows a common pattern: teams encode workflow recipes into tools because models once needed guidance, then keep those recipes long after the model can sequence actions itself. The result is control drift, where the organisation thinks it has built precision but has actually created brittle access logic. Practitioners should treat overfitted orchestration as a lifecycle failure in AI governance.

Deterministic validation remains the part worth preserving. The strongest controls in the article are the ones that enforce schema checks and sandboxed execution at the boundary, not the ones that tell the model how to think. That aligns with identity security practice: govern the point of action, not the narrative around it. For teams running AI-assisted workflows, this is where policy, logging, and enforced validation belong.

Model-driven workflows will force IAM and NHI teams to rethink tool scoping. If the model can now infer the workflow, organisations should stop equating more custom tools with more control. The better pattern is narrow capability exposure, explicit authorization boundaries, and clear ownership of each tool identity. Practitioners should expect AI governance to move from workflow design toward permission design.

Portable knowledge and connected capability should be separated. Skills, documentation, and examples belong in portable instruction layers, while authenticated system access belongs in governed infrastructure. That separation reduces duplication and clarifies where access is actually being granted. For identity programmes, the practical conclusion is simple: if a control can live outside the protocol, it usually should.

What this signals

Tool sprawl is becoming a governance signal, not just an engineering smell. When AI systems accumulate wrappers around shell commands, documentation lookups, and validation steps, the result is often more permission surface than control. IAM and NHI teams should track which tools actually enforce a boundary and which ones simply relabel existing capability.

Access scoping should now extend to AI toolchains and plugin identities. The practical problem is no longer whether an AI can use a tool, but whether the tool identity is scoped, logged, and revocable in a way auditors can understand. If your programme cannot answer that question, the model can probably do more than you think.

From our research, only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to The State of MCP Server Security 2025. That low baseline suggests most programmes are still experimenting with control design rather than operating it. The next step is to align AI tool permissions with the same discipline used for privileged workloads and service accounts.

For practitioners

• 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. Retire tools that only restate generic commands and keep only those that enforce sandboxing, validation, or authenticated access to live systems.
• 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. This reduces the temptation to encode recipes into MCP and makes access reviews more meaningful.
• 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. Access scoping should cover the tool itself, not just the human or model using it.
• Preserve deterministic validation at the boundary Keep schema validation, test execution, and policy checks in the engine or service layer rather than in prompts or orchestration scripts. That way the model can change while the control remains stable.

Key takeaways

• MCP becomes risky when it is used to encode workflow recipes that the model can already execute on its own.
• The controls worth keeping are the ones that enforce boundaries, such as sandboxed execution and deterministic validation.
• AI tool permissions need the same identity and privilege discipline as other non-human identities.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• Tool scoping: Tool scoping is the process of limiting which actions an AI client or service account can invoke through a protocol or platform. It is the control that prevents conversational access from becoming broad execution, and it should align with the smallest set of operations needed for the task.
• Deterministic Validator: A deterministic validator is a rule-based check that returns the same result for the same input. In GenAI governance, it is used for objective conditions such as secrets exposure, PII leakage, jailbreak attempts, toxicity, or gibberish, where repeatability matters more than interpretive nuance.

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.

👉 TENZIR's full post shows the experiment details, tool comparisons, and the planned MCP refactor.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and agentic AI identity. It is designed for practitioners who need to translate identity controls into operational policy across modern security programmes.