MCP OS: A Policy-First Capability Environment for Model-Neutral AI Agents

Introduction

The center of gravity in applied artificial intelligence is moving from short, self-contained conversations toward delegated tasks that invoke tools, inspect environments, and run over longer time horizons. OpenAI reports that sampled Codex users increasingly request tasks that would take more than an hour of human work, while adoption has expanded beyond engineering into business functions. This shift creates a systems problem. A model can reason about a task, but useful work often requires access to source repositories, files, services, identity systems, browsers, devices, or databases. Each access path introduces authorization, safety, observability, and recovery requirements.

MCP is a major step toward interoperable tool access. The protocol defines an open standard that lets AI applications connect to external data, tools, and workflows. Yet a standard connection surface is not an operating environment. A production deployment must also decide which capability may run, under which identity, with what approval, within which task, and with what audit record. In parallel, enterprise identity products are beginning to treat agents as governed principals with lifecycle and access-management needs. These developments motivate a layer that is neither a model provider nor merely a server catalog.

MCP OS is an early implementation of that layer. Its premise is that models and MCP servers should be replaceable at the edge while a capability environment preserves policy, approval, task-state, audit, and normalization boundaries. The system is deliberately incomplete. Its value as a case study lies in showing how the governance layer can be designed before broad operational access is granted.

Method and Evidence Boundary

This version is a systems analysis of companion commit 33154ee (July 29, 2026); its full 40-character identifier is recorded in the repository citation. Market context is drawn from primary sources. Implementation claims are based on source code, tests, architecture documents, threat model, user and test guides, release-acceptance material, and the local-Ollama beta guide. The analysis classifies functionality as verified when it exists in the present codebase and is covered by repository tests or direct source inspection; verified beta when it has bounded installed or recorded local evidence but is not validated as a production service; and approved design when an agreed architecture exists but the corresponding package or qualification is not executable.

This distinction is material. The present implementation includes a local-Ollama path, a bounded terminal runner, and a signed packaged loopback companion beta with paired clients, task-scoped authority, receipts, Stop, and a one-tool production catalog. It does not establish durable enterprise storage, remote operation, enterprise identity, a complete suite of capability servers, or empirical qualification of general control across all installed applications. The figures and market analysis therefore describe an architectural position and an implementation trajectory, not a claim that all surrounding layers are deployed.

Background: From Agent Tools to Capability Environments

MCP and the interoperability problem

MCP addresses fragmentation in the way AI hosts reach tools. The official introduction compares the protocol to a universal connection point: an AI application can connect to a local file system, a database, a search engine, or a specialized workflow through a shared approach. This is valuable because agents otherwise need bespoke integration code for every provider-tool pairing. MCP's abstraction, however, is intentionally narrower than organization-wide policy or identity management.

That boundary matters in an enterprise setting. A tool may be technically discoverable yet still be inappropriate for a particular agent, task, user, time window, or input. The governance requirement grows with capability consequence. Reading an allowlisted project summary is not equivalent to staging a Git change, deleting data, or transmitting customer information. Consequently, a tool protocol benefits from a companion control plane that can express risk, decisions, approvals, and audit semantics independently of a particular model or server implementation.

The emerging agent-governance market

The market can be understood as several complementary layers rather than a single winner-take-all category. Model providers compete on reasoning, latency, cost, and modality. MCP and related interfaces supply tool interoperability. Identity and security providers govern principals, access rights, and lifecycle. Coding agents and IDEs package agentic interaction into developer workflows. A capability environment sits between those layers, translating an agent's requested action into a policy-governed, auditable execution path. Microsoft Entra's agent identity documentation illustrates the surrounding market direction: agent identities can be created, sponsored, governed, and granted access in an enterprise lifecycle.

\begin{figure}[ht] \layer{bluegray}{Reasoning engines GPT, Claude, Gemini, Grok, local models} [3pt]\(\downarrow\) [3pt] \layer{lightblue}{MCP OS capability environment Task state $\mid$ policy $\mid$ approvals $\mid$ audit $\mid$ normalization} [3pt]\(\downarrow\) [3pt] \layer{bluegray}{MCP and native capability boundary Versioned tool descriptors and transport-neutral capability contracts} [3pt]\(\downarrow\) [3pt] \layer{lightblue}{Operational systems Projects $\mid$ files $\mid$ Git $\mid$ future services, devices, and data} \caption{The proposed capability-environment position. The middle layer remains stable as models and operational connectors change.} \end{figure}

System Architecture

Foundation components

MCP OS is organized as a pnpm and TypeScript monorepo. Its Phase 1 foundation establishes shared contracts, configuration, persistence seams, audit services, and a deterministic mock model provider. Phase 2 adds policy, approvals, task state, and the agent runtime. Phase 3 completes a narrow, guarded set of local capability services and adds a local-Ollama beta runner. The architecture document states the governing principle directly: model and capability contracts are provider- and transport-neutral.

The system separates responsibilities into focused packages. Shared types represent normalized contracts. Configuration validates application and model settings. Persistence is represented by interfaces rather than a production database dependency. Audit stores append-only events through a narrow service boundary. The model gateway establishes a normalized provider contract, while the policy engine and agent runtime provide governance and lifecycle behavior. This structure avoids allowing raw provider payloads or raw MCP protocol payloads to dictate the runtime's internal model.

Task state and approval

The runtime defines a closed lifecycle covering task creation, planning, approval, tool execution, synthesis, completion, failure, and cancellation. Its state machine rejects transitions that are not present in the graph. The minimal in-memory runtime can submit a task for approval or straight to completion, supports resumption only from the approval state, rejects resumption for other states, and refuses cancellation of a terminal task. Audit events capture task creation and cancellation in the present foundation.

\begin{figure}[ht] \fbox{\begin{minipage}{0.88\linewidth} Task governance flow [5pt] created $\rightarrow$ planning $\rightarrow$ \begin{tabular}{c} policy decision [-2pt] \end{tabular} [5pt] \begin{tabular}{@{}c@{\qquad}c@{\qquad}c@{}} \fcolorbox{green}{white}{allow} & \fcolorbox{amber}{white}{ask} & \fcolorbox{graytext}{white}{deny} $\downarrow$ & $\downarrow$ & $\downarrow$ executing_tool & awaiting_approval & no side effect $\downarrow$ & $\downarrow$ & audit decision synthesizing & approval + matching fingerprint & $\downarrow$ & $\downarrow$ & completed & executing_tool & \end{tabular} [5pt] Cancellation may move non-terminal states to \texttt{cancelled; failure is terminal.} \end{minipage}} \caption{The policy and task-state model. Approval is an explicit state, not an informal user-interface convention.} \end{figure}

The approval service is designed to bind a consent decision to a narrow context. An approval has an identifier, task identifier, input fingerprint, expiration, and approval status. Consumption fails if the approval is absent, unapproved, expired, or associated with a mismatched fingerprint. This is a small but important design choice: approval of one proposed action should not silently authorize a different action.

Policy engine

The policy engine evaluates rules with three effects: allow, ask, and deny. Rules have priority and may target a capability identifier. The engine filters matching rules, orders them by descending priority, and selects an explicit denial before considering the highest-priority remaining match. If no rule matches, it returns deny. This makes the default posture conservative and allows a specific prohibition to override a broader permission. The present implementation is intentionally small: it establishes the semantics that later policy inputs, identity systems, and capability services can consume.

MCP normalization and capability services

Phase 3 adds a separate MCP client package. Its tool adapter accepts a descriptor containing a server identifier, tool name, version, description, input schema, risk level, and side-effect declaration. It validates server and tool identity characters, then produces a normalized capability identifier in a versioned form such as mcp.server.tool-vN. Execution is represented as an internal function accepting an unknown input and delegating to an invoker. The key architectural result is that the runtime can reason about a common capability shape without depending on raw MCP payloads.

\begin{figure}[ht] \fbox{\begin{minipage}{0.88\linewidth} Tool-normalization boundary [6pt] \begin{tabular}{>{}p{0.24\linewidth} >{}p{0.27\linewidth} >{}p{0.25\linewidth}} \rowcolor{bluegray} MCP descriptor & Boundary & Normalized capability serverId, name, version, description & identity validation and versioned naming & id, description, execute(input) \end{tabular} [7pt] Example: server id git, tool name status, version 1 becomes a versioned internal capability id. \end{minipage}} \caption{MCP tools are adapted at the boundary rather than passed as protocol-specific objects into the capability runtime.} \end{figure}

The connection manager separately registers a loader for each server and records a health state. A successful tool listing marks a server healthy; a loader failure marks it unhealthy and returns an empty tool list. It applies a bounded timeout, supports reconnect, rejects duplicate normalized capability identifiers, and emits audit callbacks. This failure isolation avoids presenting a temporarily failed server as a successful discovery result. It is not a complete remote MCP transport or a universal discovery system.

Three guarded capability services extend the architecture. The Project service enforces an allowlist and reports bounded tree, package, dependency, and configuration summaries. The Filesystem service canonicalizes paths, blocks traversal and symlink escapes, bounds reads and searches, redacts credential-like paths, and returns metadata. The Git service exposes bounded read operations and requires a scoped approval for branch creation, staging, commits, and pushes; force pushes, resets, deletions, cleanup, and arbitrary shell execution are unavailable. Configuration examples and cross-server security tests support these boundaries. These services are deliberately narrow interfaces, not complete production interfaces.

Local-Ollama beta demonstration

The repository also includes a terminal demonstration that connects a locally installed Ollama model to a disposable fixture repository. The runner asks the model to inspect a generated project through a small allowlisted tool set, then requires an explicit terminal approval before invoking the Git branch-creation capability. In a recorded local run using qwen3.5:9b, the model completed project_summary, read_package, and git_status; after approval, it created demo/approved-change. The audit timeline recorded readiness, fixture creation, model responses, each tool completion, the approval request and grant, and completion. This is evidence of an end-to-end beta path, not a benchmark or a claim that arbitrary models, repositories, or tools are production-ready.

Persistent local companion beta

The current beta packages MCP OS as a login-started, loopback-only macOS companion rather than embedding governance in a particular frontend. A native helper supplies the narrow macOS boundary for screen observation, application activation, mouse and keyboard input, permission diagnosis, and cancellation. The companion owns the higher-order control plane: client pairing, policy evaluation, immutable per-run authority, local audit and receipts, evidence retention, bounded operator support diagnostics, and an operator-facing Stop control.

The production MCP catalog exposes one model-facing entry point, mcp_os_execute. It creates or continues a task-scoped run, executes a typed computer, browser, Terminal, Project, Filesystem, or Git request, reports status, and stops the run. Raw executor, map-administration, and diagnostic tools are development-only. The unified gateway routes an allowed typed request to bounded native input, mapped semantic GUI, browser, terminal, Project, Filesystem, or Git execution; it requires request-bound proof before reporting completion. This is a deliberately smaller production surface than the internal capability inventory.

The pairing model separates client identity from action authority. Every new client begins read_only; the operator selects approve, delegate, or full for a particular run, and a model cannot elevate that authority. Terminal requests are classified by MCP OS and await matching approval when policy requires it. Input actions require a fresh, run-bound observation that matches display geometry and foreground context. Stop cancels pending work and fences subsequent input. This is a completed packaged beta boundary, not evidence of general all-app task completion.

Security and Governance Analysis

The system's security model is most accurately understood as progressive exposure. The threat model establishes schema validation at public boundaries, avoids logging configuration secrets, and represents audit records through append-only persistence interfaces. Phase 2 adds deny-by-default policy and approval behavior before side effects. Phase 3 protects the local-capability boundary with scoped allowlists, canonical filesystem path enforcement, bounded and redacted output, duplicate-capability rejection, connection health reporting, bounded Git reads, and approval-gated Git writes. Destructive Git operations and arbitrary shell execution remain unavailable.

This separation is valuable for two reasons. First, it prevents a policy-free tool catalog from becoming the de facto runtime before governance semantics are defined. Second, it makes residual risk visible rather than hiding it behind product language. The companion stores captures below an owner-only local data root, rejects existing or symlinked capture destinations, and gates protected effect-capable applications even under delegated authority. MCP OS does not claim to eliminate prompt injection, identity misuse, or server compromise. It also does not claim isolation from another malicious process already running as the same macOS user; a hardened public release would need a caller-validated native boundary.

The connection between agent capability and identity must remain explicit. Microsoft frames agent identities as principals that should be managed and governed throughout an agent lifecycle. MCP OS does not yet integrate an identity provider. It can nevertheless serve as an architectural seam: identity can produce a trusted execution context, policy can evaluate a capability request against it, approval can bind the resulting action, and audit can preserve the decision trail.

Market Position

MCP OS is not positioned as a replacement for reasoning engines, identity platforms, IDEs, or the MCP standard. Its market position is the coordination layer that can compose those categories without collapsing them into one vendor-specific surface. Figure maps this role by primary value proposition. The map is qualitative: it does not score specific vendors or infer undisclosed product features.

\begin{figure}[ht] \fbox{\begin{minipage}{0.88\linewidth} Qualitative market map [5pt] \begin{minipage}[t]{0.46\linewidth} Reasoning and end-user work [3pt] \raggedrightModel providers and agent products Model quality, interaction, task completion, and user experience. [8pt] Tool protocols and connector ecosystems Standardized discovery and invocation across tools, data, and workflows. \end{minipage}\hfill \begin{minipage}[t]{0.46\linewidth} Control and governance [3pt] \raggedrightIdentity and security platforms Authentication, lifecycle, access governance, and enterprise controls. [8pt] \colorbox{lightblue}{\parbox{0.94\linewidth}{MCP OS capability environment Policy, approval, task-state, audit, and normalized capability execution between changing agents and operational systems.}} \end{minipage} [8pt] The categories overlap in practice; the figure identifies the primary architectural center of gravity. \end{minipage}} \caption{MCP OS occupies the capability-environment position between interoperability and enterprise governance.} \end{figure}

This position has three potential advantages. First, it can support model substitution: a capability is represented internally rather than coupled to a particular model provider's tool representation. Second, it can support tool substitution: a normalized capability contract can outlive a particular MCP server or native implementation. Third, it can centralize governance semantics without assuming that one vendor must own every model, connector, device, and identity system. These are design advantages, not yet measured economic advantages.

The strategic challenge is equally clear. The layer is valuable only if it becomes operationally trusted. That requires reliable identity integration, durable storage, observable policy decisions, capability-level security hardening, and usable administration. The current codebase supplies some governance primitives but does not yet demonstrate the scale, integrations, or operational evidence needed to substantiate a production-enterprise claim.

Implementation Maturity and Limitations

Figure summarizes the maturity boundary. The chart intentionally uses categorical status rather than fabricated coverage percentages. It makes the paper's main qualification visible: the foundation is real, but the broader platform remains incomplete.

\begin{figure}[ht] \begin{tabular}{>{}p{0.27\linewidth}>{}p{0.39\linewidth}>{}p{0.23\linewidth}} \toprule System area & Evidence-grounded scope & Status \midrule Core contracts, policy, approvals, task state & Model-neutral contracts; deny-by-default rules; scoped approval; closed lifecycle & \textcolor{green}{Verified} Audit and persistence & Foundation seams plus companion-local audit, receipt, and evidence retention & \textcolor{green}{Verified beta} MCP client boundary & Versioned descriptors; timeout/reconnect; collision rejection; health and audit callbacks & \textcolor{green}{Verified beta} Project, Filesystem, Git services & Allowlists; canonical and redacted filesystem access; bounded Git reads; approval-gated writes & \textcolor{green}{Verified beta} Local model demonstrations & Ollama fixture runner and bounded macOS computer-control beta & \textcolor{green}{Verified beta} Persistent local companion & Signed loopback beta, pairing, one production tool, local audit/receipts, Stop, and bounded operator support diagnostics & \textcolor{green}{Verified beta} General-control qualification & Five executor scenarios require ten clean proof-backed samples each; the release ledger is not run & \textcolor{amber}{Unqualified} Production platform layers & Durable storage, broader server coverage, remote operation, and enterprise identity integration & \textcolor{graytext}{Internal 1.0/1.1 design} \bottomrule \end{tabular} \caption{Implementation maturity classification derived from the repository source, threat model, and Phase 3 plan.} \end{figure}

Several limitations follow directly. The agent runtime and companion evidence stores are local rather than an enterprise durability service. The policy engine does not yet demonstrate attribute-rich enterprise policy evaluation. The companion is deliberately loopback-only and does not provide remote operation, OAuth, multi-user tenancy, or enterprise identity. Its one-tool surface is a bounded beta: completion requires executor evidence bound to the request, but that contract alone is not an empirical claim of arbitrary-app reliability. The five-executor release ledger remains unrun, requiring ten clean samples for each of Calculator, TextEdit, a loopback Chrome fixture, unsent Mail, and a fixed Numbers adapter. Consequently, neither a source suite nor historical installed acceptance evidence may be represented as a general all-app or performance result. The Ollama runners remain proofs of concept over a generated fixture and bounded desktop workflow, not benchmarks of model reliability, repository safety, throughput, user experience, or enterprise security effectiveness.

These limitations should not be treated as incidental. They define the appropriate interpretation of MCP OS: a governed capability-runtime foundation. The platform thesis is plausible only if later phases preserve the present boundary discipline while adding robust authentication, authorization, storage, observability, and connector behavior.

Implications and Future Work

The architectural lesson is that agent infrastructure benefits from separating reasoning from authority. Models can change quickly. Tool protocols can improve. Local and cloud execution environments can coexist. The stable system boundary should be the policy-governed capability request: who or what requested it, what capability is implicated, what input is proposed, what decision applies, whether approval is required, and what event record results.

Near-term work follows from the remaining qualification gap. MCP OS should execute the existing five-executor contract in a dedicated operator-approved lab: each scenario must produce its own fresh observations, MCP results, audit events, receipts, final proof, and cleanup proof before it contributes to an aggregate result. The fixture coordinator must remain internal, never become a customer-facing MCP tool, and prepare only reviewed foreground, reset, and loopback browser state. Capability services should continue to be exercised against representative repositories and operational back ends while retaining their narrow allowlists and approval gates. Remote transport, cloud evidence, and enterprise identity integration remain deferred internal 1.0/1.1 work rather than implicit consequences of the local companion.

Research evaluation should then shift from structural correctness to empirical evidence. Useful metrics include policy-decision latency, approval completion time, rate of denied unsafe operations, audit completeness, recovery from connector failure, model-switching friction, end-to-end task success, and operator comprehension of a proposed action. Comparative work should distinguish a capability environment from both generic agent frameworks and tool-protocol implementations.

Conclusion

MCP makes it easier for AI applications to reach tools and data. It does not by itself decide when that reach should be exercised. MCP OS is an early effort to make that decision layer explicit. At v1.1, its implementation establishes model-neutral contracts, deny-by-default policy, scoped approvals, task-state foundations, audit seams, guarded capability services, a local-Ollama beta path, and a signed loopback companion beta. The companion exposes one public MCP entry point that mediates typed requests through policy, task-scoped authority, execution receipts, request-bound proof, and Stop. Its market position is therefore not ``another model'' or ``another MCP server,'' but a policy-first capability environment between agent reasoning and operational systems.

The work remains incomplete, and v1.1 preserves that qualification. The verified beta demonstrates a bounded local companion and a constrained, audited, approval-gated tool path; it does not establish production readiness or general all-app task completion. The unrun five-executor ledger is an explicit release gate, not a missing footnote. The broader opportunity is credible only if the implementation advances with durable, identity-aware, observable, securely bounded behavior and empirical qualification that reports both successes and failures.