Skip frontier models and you fall behind. Use them and your alpha leaks. That’s the trap.

Every enterprise runs on something no competitor and no vendor can replicate: its proprietary data, its workflows, its institutional knowledge, its evaluations, its business rules, its decision rights. Call it the enterprise’s alpha — the accumulated operating edge that makes one company outperform another running the same software on the same market. It’s the asset that took years to build and can’t be bought off a shelf.

Agents share “enterprise alpha” with frontier models. Ungoverned use can easily leak alpha. The moment an agent harness reaches into enterprise systems to read a record, call a tool, or pull context into a prompt, the alpha starts moving — out of the systems that hold it and into models and workflows that act on it. Used well, that movement turns proprietary context into compounding advantage. Left ungoverned, the same movement is exactly how the edge escapes: over-scoped tools, un-vetted context, actions taken against systems of record with no basis for who authorized them or why. Governing the alpha isn’t a compliance nicety — it’s the difference between an agent that extends your advantage and one that quietly gives it away.

That’s why the alpha needs a governed gate — a single point every agent must clear before it can touch proprietary context or take an action, where what’s allowed in and what’s allowed out is decided deterministically rather than left to a model’s discretion. That gate is MCP Context Authorization. What follows traces why three of the most-read voices in tech converged on the same underlying asset from three different angles — and why the protocol just made that gate real.

Karp’s warning: don’t transfer the alpha

Palantir CEO Alex Karp put the sharpest point on it in a CNBC interview this year: enterprises want to own the means of production instead of transferring their alpha to OpenAI or Anthropic. Karp’s answer is architectural: build the frontier application so it performs like a frontier model, without ever handing your business’s proprietary edge to someone else’s model in the process.

That proprietary edge is what he calls the enterprise’s alpha, and it’s the term the rest of this argument gets built on.

Chamath’s stack: everything below the harness is commodity risk

Chamath Palihapitiya picked up Karp’s term directly. In his August 2026 “AI investing guide,” he laid out six layers of the AI trade — Land/Power/Shell, Silicon, Clouds, Models, Harnesses, Applications — and ranked them by durability, not hype. Models are the open question: he flagged that a meaningful share of today’s model revenue may be inflated by tokenmaxxing and poor model behavior, meaning that layer’s economics could compress even as usage climbs.

Layers five and six are where he’s actually put his own capital. The harness, he argues, is what lets an enterprise own its proprietary context — its data, workflows, evals, and business rules — which is exactly what Karp calls the enterprise’s alpha. A harness that hands that context back to the enterprise, rather than trapping it inside a vendor’s model, is what creates real model-agnostic switching costs.

Nadella’s loop: the same asset, seen from inside the firm

Satya Nadella asks: what happens to a firm’s competitive advantage once intelligence itself is something you can rent from anyone? For a century, durable advantage lived in people, process, customer memory, and tacit operating knowledge. A foundation model doesn’t erase that advantage — but it flattens it, because the same general intelligence is available to every competitor at the same price.

His answer is that every firm needs its own private loop — a hill-climbing machine or a flywheel where a model keeps learning from the company’s own tasks, traces, evaluations, and outcomes. Private evals become strategic memory. Workflow traces become training signal. A company that builds the loop turns ordinary daily work into accumulating, owned IP. The frontier belong to whoever owns the best loop.

Three people converging on one industry zeitgeist: it’s about the harness. the enterprise has alpha, and the entire current AI trade is a bet on whether that alpha compounds inside the company or leaks to whoever’s on the other end of the wire.

Now enterprises know what to build. The question is where to start.

Enterprises are staring to build their harnesses to own and execute their alpha — the data, workflows, evals, and business rules that make up the business’s actual edge. But a harness sitting on its own doesn’t do anything. That alpha has to flow to it — has to move out of enterprise systems and into a harness that can orchestrate it alongside a model’s intelligence.

An enterprise alpha flow is the complete path proprietary context takes from enterprise systems, through gateways, agent harnesses, and runtimes, into models, and back into business applications, human decisions, and enterprise actions.

That flow is the picture above: alpha leaves its source, clears one governed checkpoint, gets orchestrated by a harness and a model, and returns as a decision, a record, or an action — closing the loop Nadella describes, or leaking out of it.

So enterprises know what to build. The real question most of them haven’t answered yet is where the flow actually starts.

This is where MCP comes in

MCP is the layer that starts to understand an enterprise’s systems, tools, and data — the raw material of the alpha itself — and exposes it to the harnesses that need it. It’s the layer where the enterprise’s proprietary context first becomes reachable by anything outside the enterprise’s own walls. Every tool that gets exposed through MCP is a slice of alpha becoming available to a harness, and by extension, to whatever model that harness is talking to.

Which means this layer needs a high level of scrutiny. A mistake here doesn’t leak a log line — it exposes your alpha directly, the exact asset Karp, Chamath, and Nadella are all telling enterprises not to give away.

The new spec makes governing the harness layer the default starting point

The 2026-07-28 MCP specification is the largest change to the protocol since remote MCP launched, and it lands at exactly the right moment. The core shift is a move from a stateful, session-based protocol to a stateless request/response core — any call can now land on any server instance behind a plain load balancer, with no session state to keep in sync. Every request carries its method and tool name in Mcp-Method and Mcp-Name HTTP headers, so gateways can route and meter on the header directly instead of parsing bodies. The authorization model was hardened to match: issuer validation per RFC 9207, a formal move away from Dynamic Client Registration toward Client ID Metadata Documents, and client credentials now bound to the specific issuer that minted them.

MCP is the de facto starting point for governing the harness layer. It is harness infrastructure carrying the enterprise’s alpha, addressable, statelessly routable, and identity-checked at the connection level by default.

MCP Context Authorization applies to all five layers of the harness

MCP Context Authorization applies to every layer that touches enterprise context. To see why, start with what a harness is made of.

An agent is a model plus a harness. The harness is everything that isn’t the model — the code, configuration, and execution logic that turns a raw model into something that can do work. In the anatomy now settling into consensus, a harness has five recurring layers:

• System prompt — the standing instructions that define the agent’s role, boundaries, and objectives.
• Tools and skills — everything the agent can do: the tools it can call and the skills it can invoke, exposed to it through MCP.
• Memory and external data — the context it reads: retrieved documents, database records, API responses, log files, and the facts it carries across sessions.
• Orchestration — the logic that spawns subagents, hands work between them, and routes across models.
• Infrastructure — the filesystem, sandbox, and execution environment where its actions actually run.

MCP is the conduit for each layer. That is what makes it the right place to govern. Every layer of the harness draws its context through this conduit, which means every layer can have context authorization applied to it — a set of policies that decide what context each layer is allowed to reach, under what conditions, and with what outcome. Identity at the door doesn’t do this. RFC 9207, CIMD, and issuer-bound credentials answer whether the harness is who it claims to be; they say nothing about whether this layer should reach this context right now. That decision is a policy decision, and it has to be made at each layer.

This is where Arbiter comes in. MCP Context Authorization applies context authorization to each harness layer through three kinds of policy, each enforced by a corresponding part of Arbiter:

Workflow policy (ARBITER.WORKFLOW). A series of gates that every element of enterprise context — every tool, resource, and data product — must pass before it is sanctioned for use inside an agent at all. This is the vetting layer: nothing becomes available to a harness until it has cleared the workflow gates that qualify it.

Runtime policy (ARBITER.RUNTIME). Conditions an agent must satisfy at the moment it acts, before Arbiter will evaluate anything else. Runtime policy is where the agent has to produce evidence — attributes it carries into the request. A customer-facing agent must present on-behalf-of (OBO) credentials and carry user consent. An agent using a data product must show evidence of license entitlement. A B2B agent reaching a payment or commerce system must show the entitlements — group, role, scope — tied to the specific operation it’s requesting. Runtime policy is the precondition; if the evidence isn’t there, nothing downstream runs.

Deterministic policy (ARBITER.DETERMINISTIC). The decision itself, made after the agent reasons and before it acts: ALLOW, BLOCK, or ESCALATE to human review. This is the enforcement most people already picture when they hear “governance” — but it only means anything because workflow policy qualified the context and runtime policy proved the conditions first.

Those three dimensions apply to every component of the harness. Take them one at a time.

Tools and skills. Everything an agent does, it does through a tool, and MCP is how tools are exposed to it. Workflow: a tool is available to a harness only after it clears the gates that vet it — what it does, what it touches, what it’s allowed near. Runtime: when the agent calls that tool, it must produce the attributes the operation requires — the entitlements, the consent, the scope tied to that specific action. Deterministic: the call is then allowed, blocked, or escalated at the moment the model’s decision becomes a real effect.

Memory and external data. Beyond tools, MCP servers expose resources — file contents, database records, API responses, log files, and more — the proprietary context a harness pulls into its prompts. Massive context is pulled into context windows each day creating massive alpha exposure. Workflow: each resource is sanctioned before any agent can reach it — this database record, that log file, qualified for use. Runtime: the agent pulling it must show entitlement to that specific data — license, consent, or role. Deterministic: the retrieval is allowed, blocked, or escalated per request, bound for a specific prompt and model.

Orchestration and subagents. Harnesses spawn subagents often sharing context between them, and reliability degrades across those handoffs: a chain that passes context freely is how a scoped agent quietly becomes an unscoped one. Workflow: which delegation paths are sanctioned at all — which agent roles may hand work to which others. Runtime: the delegating agent must carry the attributes that authorize the handoff, and they must survive the hop rather than being assumed from the parent. Deterministic: each handoff is allowed, blocked, or escalated on its own, not inherited because the parent was trusted.

Infrastructure and execution. This is where the agent actually runs code — the filesystem it reads and writes, the sandbox it executes in, the environment and plugins configured around it, the gateways it reaches through. Workflow: the gates here sanction the execution surface itself — which filesystems and sandboxes are approved, which non-MCP tools an agent may use, which environment and plugin configurations are allowed, which skills are approved for a given plugin, which gateways are permitted, and what constitutes safe code execution. Nothing runs on an unsanctioned surface. Runtime: the record of what this session actually did — which shell commands were executed, which filesystem modifications were made — so that action is evidenced, not assumed. Deterministic: each command or write is allowed, blocked, or escalated at the moment it’s attempted, against the approved configuration rather than after the fact.

Read those together and the perception inverts. MCP Context Authorization is not a gate the harness passes through on the way to the real work. It’s where the harness’s own components — its tools, its memory, its orchestration, its cost — are actually governed, along three dimensions, by Arbiter. That is the distinction between adopting MCP as a tool and treating MCP Context Authorization as part of the harness itself.

Evaluations close the controls loop

There’s a fifth harness component, and it’s the one that makes the other four improve over time: evaluations. Every agent run is stored — the full record of what context the agent pulled, what attributes it produced, what actions it requested, and what Arbiter decided.

Because the run is captured against the policies that governed it, actual behavior can be compared to the policy that shaped it — and where a workflow gate was too permissive, a runtime requirement too strict, or a deterministic decision wrong in either direction, the policy adjusts. This is a reinforcement loop for Arbiter. Each run makes the next set of policies sharper, and the governance layer eliminates accrued drift. The harness gets more capable; the policies governing your alpha get more precise.

That same record produces a second capability: containment. Containment is the kill switch to take agents offline in the face of machine-speed incidents and adversarial actions. Because Arbiter already sits in the path of every action and knows what every governed agent is permitted to do, containment is handled as another action control.

This is what LangGuard’s Arbiter-Governed MCP Tools Catalog puts into practice. A tool or resource enters the catalog only after it clears workflow policy — vetted, authenticated, authorized, and audited — and each is mapped to the specific slice of alpha it exposes rather than assumed safe by default. As governed context connects to harnesses and harnesses connect to models, the enterprise alpha flow stops being a diagram and becomes something enforced, per call, along all three dimensions.

The starting point for taking control of your alpha

MCP Context Authorization is the first step in taking control of your enterprise alpha — the one governed checkpoint every piece of proprietary context and every tool has to clear before a harness, a model, or a learning loop ever gets to touch it. Karp said don’t transfer it. Chamath said build the harness that keeps it. Nadella said the firm that owns the loop owns the frontier. LangGuard is the starting point for securing and governing the harness layer that makes all three of those things possible at once.

The Alpha is yours. The model is rented. MCP Context Authorization is where you take control of it.