Enterprise Context Challenges

·Matt Barker
Enterprise Context Challenges

Context is the information and tooling an AI model uses to complete a task, from documents and reports to APIs and SaaS integrations.

Giving AI access to context ‘feels’ easy. With MCP servers, Skills, or even a simple CLI, you can connect AI to real systems in hours, not months. But the simplicity is deceptive.

Once you move beyond demos, a harder problem appears: returning the right context. Weak identity controls, poor implementation and connectivity sprawl can quickly lead to context flooding, prompt injection, and loss of control.

By preparing your APIs, using systems you already trust, and building the right MCP servers with Skills, many of these problems can be avoided. This blog explores the challenges and some practical principles to follow.

Identity and Auth

Identity is the first challenge.

Giving agents broad access to enterprise systems without context-aware authorization is a little like handing out hotel master keys. A guest, cleaner, and engineer may all enter the same building - but you don’t want them to access the same rooms. Identity alone is not enough - context and authorization is what matters.

As a simple example: a senior investment manager couldn’t give her team read-only access to investment notes in their CRM. At its worst, a vendor MCP returned competitor’s data.

MCP gateways help early. Like security at the front desk, they authenticate visitors and apply broad access rules. But fine-grained control requires deeper domain context, and that context lives inside the MCP server itself.

Context Engineering

It’s easy to assume more context leads to better results. In reality, the opposite is often the case. Context is constrained. Every piece of data competes for attention - increasing cost, degrading performance, and expanding risk.

In practice, things break quickly. In one case, just two MCP servers introduced too many tools, flooding context and stopping work entirely. In another, an n8n workflow showed early promise, then ground to a halt once multiple MCP servers were introduced.

Large models can mask some of these problems but smaller, cheaper models make it very obvious.

High token burn is one thing, but critically, poor context control can make your task impossible to complete if you get it wrong.

Context engineering is not just about retrieval. Enterprises also need to filter what comes back: removing unnecessary data, redacting PII, enforcing GDPR requirements, and preventing sensitive information from leaking.

Sprawl

There’s a growing debate between MCP, Skills, Code Mode, and CLI. In practice, teams quickly move from simple access to messy operations.

One customer described the headache of needing to connect 3+ vendor MCP servers for a single use case. Servers were inconsistent, and limitations meant users built their own scripts, OAuth flows, scheduled routines, and local workarounds. Small mistakes in this were amplified: one misplaced instruction file led an agent to run expensive BigQuery queries without the usual safeguards, alerting technical leadership .

Business leaders are left asking:

In most cases, no one is entirely sure. One Director of AI reflected: “Part of my engineers’ brains have been switched off.” Not because they’re careless, but because the pull to see what AI can do is so strong.

The result is a growing sprawl of unmanaged MCP servers and Skills, often scattered across developer laptops, with little visibility or consistent way to apply identity, policy, or control.

What to do about it

Today, most teams focus on securing the AI, the endpoint, or deploying a gateway.

But as we start trusting agent identities and connecting them to real enterprise data, the challenges quickly shift from authenticating access to controlling context. Here are a few principles that can help you prepare:

1. Treat MCP as part of critical infrastructure

Most open source MCP servers today come from unknown or unverified sources and are not production-ready. They often consume large amounts of context upfront, despite being thin wrappers around part of an existing web API.

The result is agents struggling to complete tasks reliably - especially when multiple systems are involved. If you can’t control how a server retrieves and returns context, or you can’t trust where it came from, it shouldn’t be in your stack.

2. Control your context

Vendor MCP servers (GitHub, Salesforce, etc.) are useful, but they implement vendor controls.

By design, vendor MCP servers optimise for the average user. They often expose only a narrow slice of the underlying APIs, limiting both functionality and control. This makes it difficult to apply fine-grained authorization, maintain full observability, or standardise how agents interact.

Enterprises need something different. By building and deploying your own MCP servers, you can:

Skills are a separate problem. Right now, they are self-curated and scattered across developer laptops. This creates a lack of visibility and invites prompt injection. Skills should be served and controlled from the same place as your tools: inside your MCP servers.

3. Your APIs are now AI interfaces

The market is caught up in MCP as a concept. But MCP is ultimately interpreting something we’ve had for years: APIs. If your APIs aren’t structured and well described, AI will struggle to use them correctly.

Prepare them accordingly:

The value you can get out of your context is often only as good as your API.

4. Start with a control plane you already trust

You likely already have a lot of what you need to be successful with agents:

Start there. The market is noisy and evolving quickly. Introducing new tech too early can add complexity before you understand where the real gaps are.

As one CISO put it to me:

“Any vendor who tells you they have the answer today is lying. Right now, we just need to be asking the right questions.”

–

Context is where your business value - and ultimately your defensibility - lies. How and when AI is allowed to use it will define the outcomes you get.

Most organisations are rightly focused on connecting AI to their systems, but few are thinking about what happens next.

This is where the real challenges begin.

—