MCP and Computer Use

Sources#

• A First Measurement Study on Authentication Security in Real-World Remote MCP Servers
• Anthropic's Boris Cherny: Why Coding Is Solved, and What Comes Next
• Building Prod with Jev and LangGraph
• Delegation Without Trust: An Empirical Gap Analysis of Identity, Authorization, and Runtime Governance in Multi-Agent LLM Systems
• How Anthropic's product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code)
• MCP Specification Changelog — 2026-07-28
• OpenID Foundation advances authorization for the agent era with new AuthZEN Working Group Drafts
• The Founder's Playbook: Building an AI-Native Startup
• Zero Trust for AI Agents

Summary#

Two complementary mechanisms for connecting models to external software, both built by Anthropic, both load-bearing across the Claude Code / Cowork / Chat product surfaces. MCP (Model Context Protocol) is structured, programmatic access — "the same connector you have in Claude AI" plugs into Salesforce, Google Docs, Google Calendar, Slack, Figma, Gmail, and increasingly niche industry systems. Computer use is the catchall for software that doesn't expose an MCP: the model drives the GUI directly (mouse, keyboard, screen), slow but increasingly competent on Opus 4.7. Boris Cherny's framing: "To the model, it's just tokens" — MCP / API / computer use are interchangeable substrates for the same capability.

What MCP is#

Created at Anthropic Labs (late 2024) alongside Claude Code and the desktop app by Boris's founding team. Structured tool-calling protocol with a server-client architecture:

• Server — runs alongside the external system (Salesforce, Slack, Gmail, internal CRM, niche industry SaaS); exposes available tools as typed function calls.
• Client — the Claude surface (Claude Code, Cowork, Claude AI, third-party agent) that consumes those tools.
• Same connectors everywhere. "The same MCP connector that you have in Claude AI, you hook up like Salesforce, you hook up Google Docs, Google Calendar. And then Cowork can use that. Claude CLI can use it. Claude Code everywhere can use it." — Boris Cherny

The structural property: connector logic is written once per system, consumed by every Claude surface. This is what makes Cowork viable across the existing knowledge-work tool surface (Salesforce, Docs, Drive, Slack, etc.) without Anthropic having to build per-tool integrations.

Protocol revision 2026-07-28: MCP goes stateless#

Everything above describes the connector pattern. This section dates the wire protocol, which until now the vault tracked only through what tools built on it could do. Revision 2026-07-28 (MCP Specification Changelog — 2026-07-28) is the first MCP spec version compiled here, and it is a large break from its predecessor 2025-11-25.

Evidence tier: vendor-claim. A specification is authoritative about what the protocol requires and is evidence for nothing else — not adoption, not whether any SDK or server complies, and not whether a stated requirement produces a security outcome. Read every line below as "the spec now says", never as "deployments now do".

The session is gone. Protocol-level sessions and the Mcp-Session-Id header are removed from Streamable HTTP, and the initialize / notifications/initialized handshake is deleted outright (SEP-2567, SEP-2575). tools/list, resources/list and prompts/list no longer vary per connection; a server needing cross-call state must mint explicit handles and pass them as ordinary tool arguments. MCP is now stateless by construction.

Version negotiation moved from once-per-session to once-per-request. Every request carries io.modelcontextprotocol/protocolVersion and io.modelcontextprotocol/clientCapabilities in _meta; clients SHOULD send clientInfo on each request and servers SHOULD return serverInfo in each result's _meta; a mismatch returns UnsupportedProtocolVersionError. A new server/discover RPC — servers MUST implement it, clients MAY call it — advertises supported versions, capabilities and identity up front, or acts as a backward-compatibility probe on STDIO.

The server can no longer initiate. Multi Round-Trip Requests (MRTR, SEP-2322) replace every server-initiated request — roots/list, sampling/createMessage, elicitation/create. A server needing more input returns an InputRequiredResult (resultType: "input_required") carrying inputRequests; the client supplies inputResponses on a retry of the original request. All results now carry a required resultType, and results from earlier-protocol servers that omit it MUST be treated as "complete". Change notifications move to a single opt-in long-lived subscriptions/listen stream (replacing the HTTP GET endpoint and resources/subscribe), with request-scoped notifications like notifications/progress still riding their own request's response stream.

Caching becomes part of the contract. tools/list, prompts/list, resources/list, resources/read and resources/templates/list results MUST now carry ttlMs (a freshness hint) and cacheScope ("public"/"private") via a new CacheableResult interface, and servers SHOULD return tools in a deterministic order — both justified in the changelog as client-side caching and LLM prompt-cache hit rate, not security. They have a security side effect anyway; see MCP Tool Poisoning.

Feature lifecycle: the first dated capability ledger#

The revision adopts a feature lifecycle and deprecation policy — Active / Deprecated / Removed states, a minimum twelve-month deprecation window, and a registry of deprecated features (the only one of this revision's headline changes with its own spec page). That registry is what makes protocol capabilities datable at all: before it, "is this still in MCP?" had no answer short of diffing schemas.

Capability	State as of 2026-07-28	Migration the spec names
initialize / notifications/initialized handshake	Removed	per-request _meta version + server/discover
Protocol-level sessions, Mcp-Session-Id	Removed	server-minted handles as tool arguments
ping, logging/setLevel, notifications/roots/list_changed	Removed	per-request io.modelcontextprotocol/logLevel
SSE resumability / Last-Event-ID redelivery	Removed	re-issue the request with a new ID
Server-initiated requests (roots/list, sampling/createMessage, elicitation/create)	Removed	MRTR InputRequiredResult
Tasks	Moved out of core	official io.modelcontextprotocol/tasks extension
Roots, Sampling, Logging	Deprecated (≥12mo window)	tool params / resource URIs; direct LLM provider APIs; stderr or OpenTelemetry
HTTP+SSE transport	Deprecated (soft since 2025-03-26)	Streamable HTTP
includeContext: "thisServer" / "allServers"	Deprecated	omit, or "none"
OAuth 2.0 Dynamic Client Registration (RFC 7591)	Deprecated	Client ID Metadata Documents

Also new and small: an extensions field on client/server capabilities, OpenTelemetry trace-context conventions for _meta (traceparent, tracestate, baggage), required Mcp-Method/Mcp-Name headers on Streamable HTTP POSTs plus x-mcp-header for tool-parameter-supplied custom headers, looser JSON Schema 2020-12 support in inputSchema/outputSchema, an error-code allocation policy partitioning the JSON-RPC server-error range (-32020–-32099 reserved for the spec), and a PR-based SEP workflow with seps/ markdown files.

Authorization: the spec picks CIMD over DCR#

Four minor changes move MCP's authorization layer onto ground Agent Identity and Authentication and AIMS already occupy: authorization servers SHOULD include iss per RFC 9207 and clients MUST validate it against the recorded issuer before redeeming a code; client credentials MUST be keyed by issuer identifier, MUST NOT be reused with a different authorization server, and re-registration is MUST on AS change; DCR requires an explicit application_type; and RFC 7591 Dynamic Client Registration is deprecated in favor of Client ID Metadata Documents. CIMD is a primitive AIMS §10.10 already names under Discovery — so a shipping protocol and a standards draft converged on it independently, which is a real (if narrow) data point for the plural-governance question on that page.

What the profile covers, read against an eight-requirement framework (2026-08)#

The ledger above records what changed; a gap analysis published a month later records what the profile reaches. Dantuluri & Sundi (Delegation Without Trust: An Empirical Gap Analysis of Identity, Authorization, and Runtime Governance in Multi-Agent LLM Systems, arXiv 2609.00267, empirical — VotalAI COI; this row is specification reading, not execution; full treatment on AIMS) score four agent runtimes against eight requirements for governed multi-agent delegation, and MCP authz rev. 2026-07-28 is the only one of the four that scores anything at all — LangGraph 1.2.10, CrewAI 1.15.13 and AutoGen 0.7.5 provide none of the eight. What the profile supplies:

• Mandatory Resource Indicators (RFC 8707) audience-restrict each token to a specific server, preventing cross-server token reuse — partial credit for token theft/replay and for sender-constrained credentials.
• The OAuth 2.1 resource-server model validates tokens outside the client's model — the requirement the paper calls load-bearing ("if the model gates access, a hijacked model grants access"), satisfied structurally rather than by intent.
• Short-lived tokens and revocation come free with OAuth.

What it does not supply, and the reason it is scored partial rather than mitigated: no per-hop attenuation — nothing in the profile lets a delegating agent mint a strictly narrower token for a sub-agent — and no cross-agent delegation provenance, so an agent-to-agent chain carries no cryptographic trace back to the human grant. Both are agent-to-agent properties, and MCP's authorization model is a client↔server model; the paper's broader point is that no standard profile composes attenuation, workload binding, short lifetime and out-of-model enforcement at each hop. The authors flag their own MCP cells as the ones most likely to age: "the MCP cells in particular should be re-checked against the current authorization spec."

The field-scale complement, third-party and uncorroborated here. The same paper cites Zhou et al. (arXiv 2605.22333) measuring authentication across 7,973 live remote MCP servers: over 40% expose tools with no authentication at all, and every one of the 119 OAuth-enabled servers tested carried at least one authentication flaw. That is a measurement of deployments, not of the spec, and this vault has not ingested it — cite it as reported. (All three figures confirmed first-hand 2026-09-02 on ingest of A First Measurement Study on Authentication Security in Real-World Remote MCP Servers — 7,973 servers, 40.55% unauthenticated, 119/119 flawed with 325 confirmed instances. The second-hand relay was accurate; superseded here only because one qualifier was lost in transmission, below. Full treatment: Remote MCP Authentication in the Wild.) Read together the two results say different things and both matter: the specification would still leave delegation ungoverned even if implemented perfectly, and it is very often not implemented at all.

The first-hand reading, and the qualifier the relay lost. Zhou et al. (Fudan University; one author at Central South University, arXiv 2605.22333, submitted 2026-05-21, empirical, no COI) is now ingested; Remote MCP Authentication in the Wild carries the census, the nine-flaw taxonomy, the detector and the three disclosed takeover chains. What matters here, against the ledger above:

• The 119 are not "the OAuth-enabled servers." The population is 2,428 OAuth-enabled servers, of which 1,118 (46.0%) advertise a DCR registration_endpoint; the 119 are the end-to-end-testable slice of that subset, after removing redundant, invalid, untestable and anomalous nodes. So "every OAuth-enabled server tested carried a flaw" is true but narrower than it reads — and C1's 96.6% is conditioned on a registration endpoint existing by construction. (The paper's own Discussion makes the same slip in reverse, asserting "all 1,118 OAuth-enabled servers advertise a registration_endpoint"; Finding 2.1 and Table 3 make that 46.0%.)
• The ledger's DCR deprecation is measured against a population that had not adopted the previous revision either. The paper's spec timeline stops at 2025-11-25 — CIMD preferred, DCR retained as a backward-compatibility fallback — which is the newest requirement this population could have been built against. 114 of 119 tested servers (95.8%) accept an arbitrary redirect_uri on their DCR endpoint from an anonymous registrant, and 81 (68.1%) accept authorization requests with no code_challenge or with plain, nullifying the PKCE that open-client MCP depends on. Seven of the study's nine CVEs are that one DCR flaw.
• The paper's headline mitigation is what rev. 2026-07-28 then did. Its §6.2 asks the spec to make DCR redirect-URI restriction and PKCE enforcement MUST-level and to move CIMD above DCR; two months after submission, the revision recorded above deprecated RFC 7591 DCR in favor of Client ID Metadata Documents outright. That is a genuine convergence — and the census is the reason not to score it as closed: a revision changes what conformance means, not what 1,118 running registration endpoints do.
• Below the OAuth layer entirely: 40.55% of the 7,973 (3,233 servers) expose tools with no authentication mechanism at all, and 29.00% use static tokens or API keys. The "MCP as a security surface" section below assumes a client that got past the boundary; on two fifths of live remote servers there is no boundary.

What it does not change#

No change here addresses tool-return content, tool-behavior integrity, or server revocation. The deprecated-features registry tracks spec features, not servers or tools — it is not a revocation list, and nothing in the revision requires a client to re-validate a tool it already trusts. The security consequences, including the one incidental affordance this revision does create, are worked out on MCP Tool Poisoning.

What computer use is#

Generic GUI driving as a fallback when MCP isn't available. Model sees a screenshot, decides what to click/type/scroll, executes via accessibility/automation APIs. Operates on "pretty much any piece of software that you have on your computer" (Boris Cherny).

Properties as of Opus 4.7:

• Quality — "quite good… does it quite well now, especially with 4.7" (Boris). Anthropic "is like pretty far ahead on computers."
• Latency — "very slow." Costs more tokens than MCP for the same task because each action requires a screenshot round-trip.
• Coverage — universal. Computer use is what runs when the target software has no API, no MCP, no Python library — when the only interface is a human-facing UI.

Cowork is the deployment surface where computer use most matters today: many knowledge-work apps lack programmatic interfaces.

The latency can be split off the model (2026-09). Browser automation is where the "very slow" property first got a structural fix rather than a faster model. Browserbase rebuilt Stagehand's act() so the page's interactive elements are enumerated and a cheap typed-decision model (Jev) picks the action and target, with an LLM fallback below 0.7 confidence: median act() latency 1.97 s → 0.46 s (Browserbase's early testing, reported secondhand in LangChain's Jev post, vendor-claim; no success-rate figure). It works on DOM-marked elements, not screenshots, so it is closer to a protocol view of the page than to pixel-level computer use — the enumerated-action move from Reasoning–Acting Interleaving (ReAct).

The "doesn't matter" thesis#

Boris's framing of the MCP-vs-API-vs-computer-use question:

"All this stuff just doesn't matter that much. It could be MCPs, APIs, just some sort of programmatic access cuz the model doesn't care. To the model, it's just tokens."

The substrate is fungible — the work is "expose capabilities to the model in a form the model can consume." MCP optimizes for structured / fast / cheap; computer use optimizes for universal / fallback / slow. Both reduce to token-level tool invocations.

This connects to The Bitter Lesson: as models improve, the boundary between "use an MCP" and "use computer use" should be a decision the model makes, not a decision a human harness designer makes. Boris's predictions for the next few years:

• "The model is just going to be doing all the code. It's going to be starting the agents. It's going to be building the environments." — Including, presumably, picking the right substrate to call a tool.
• Computer use specifically called out as a product area "going to get a lot better."

Cross-surface usage in the wild#

Surface	MCP examples	Computer-use examples
Claude Code (CLI)	GitHub, filesystem, Slack	Rare — engineering tools usually have CLIs/APIs
Cowork	Salesforce, Google Drive/Docs/Calendar, Gmail, Slack, Figma	Software without MCP; especially knowledge-work apps
Claude AI (chat)	Same connector set	Computer-use available
Mobile/web	Same MCP infrastructure	Browser-side, with screen-share permissions

Cat Wu's nightly slide-deck workflow (Cowork) explicitly uses MCP — Figma MCP, Slack MCP, Drive MCP — rather than computer use, because the latency cost is unaffordable for a workflow you want to complete by morning.

In the Founder's Playbook (AI-Native Startup Lifecycle)#

The playbook treats MCP as the primary integration mechanism at every stage:

• Idea stage — Cowork uses Gmail and Google Calendar MCPs to manage outreach threads, schedule customer interviews, run day-7 follow-ups.
• MVP stage — "The same MCP integrations that managed discovery logistics in the Idea stage apply here" for feedback-session scheduling, bug-report triage, iteration-cycle tracking.
• Scale stage — MCP integration with niche industry systems your competitors haven't heard of is named as a moat component (e.g., a generalist medical-billing AI breaks on 340B drug program claims; the vertical-specialist's MCP-wired competitor doesn't).

Two playbook case studies make the MCP-as-moat point concrete:

• Kindora ships an MCP connector that lets nonprofits access its prospecting tools inside Claude itself — the product is consumed via MCP, not just integrated with MCP.
• Anthropic Skills are referenced as the codification surface for recurring workflows ("how I audit a commercial lease," "how I triage a patient intake form") — Skills + MCP + memory together form the proprietary substrate the Compounding Data Moat concept describes.

Computer use is less prominent in the playbook itself, but Cowork is named as the operational layer that runs across "every stage" — and Cowork is where computer use covers the gaps that MCP doesn't.

Connection to harness-shrinkage#

Harness Shrinkage as Models Improve predicts that prompt scaffolding, permissions, and verification logic migrate inward as models improve. MCP and computer use are the opposite of harness — they are connectors between the model and the world. They don't shrink; they get broader (more systems, more interfaces) and faster (lower latency per action). The boundary that shrinks is the harness around the model's tool-selection decisions, not the toolset itself.

Caveat: as the model becomes better at picking when to use computer use vs. when to demand a real MCP, much of today's manual MCP-server-authoring effort may become "ask the model to build the connector you need." Still not a harness — more like model-authored infrastructure.

Connection to Agentic Misalignment (AM) and accountability#

MCP and computer use are exactly the substrate that turns an LLM into an agent capable of consequential action. Both extend the model's reach into:

• The customer's CRM
• The customer's email
• The customer's calendar
• Eventually, the customer's full desktop

Human-AI Accountability Redesign's "decision rights" subfront is what governs this — what does the agent do autonomously via MCP/computer use vs. what requires explicit human approval. Claude Code Auto Mode is one concrete instance: classifier auto-approves safe MCP/tool calls, blocks risky ones.

MCP as a security surface#

Zero Trust for AI Agents treats MCP as one of the highest-risk tool surfaces in agentic deployments, and supplies the concrete threat data the earlier sources lacked:

• Tool poisoning — attackers compromise MCP tool descriptors, schemas, or metadata so the agent invokes a tool based on falsified capabilities; a malicious tool can hide commands in its metadata to exfiltrate data without user knowledge.
• Rug pulls — a legitimate tool is silently replaced with a malicious version. The first documented in-the-wild malicious MCP server impersonated a legitimate email service and secretly copied all sent emails — the concrete realization of the attack-surface-scales-with-adoption worry.
• Tool chaining — combining legitimate tools (internal CRM + external email) into a harmful sequence neither would enable alone; because every call runs through trusted binaries under valid credentials, host-centric monitoring sees no malware. This is what Least Agency (capability restrictions per tool) and parameter validation are meant to contain.

The framework's prescriptions: run/host the MCP server yourself on an immutable platform after verifying and self-signing the code (Agent Supply Chain Risk); authenticate tool access with short-lived tokens bound to the calling agent's identity, never static API keys (Agent Identity and Authentication); and gate high-risk invocations behind approval escalation. Claude Code's OAuth 2.0 with auto-refresh for MCP connections and session-scoped "ask" permissions are cited as a reference implementation.

The threat model is now empirically sharpened by MCP Tool Poisoning (the dedicated concept page for this attack class). ShareLock (Liu et al., arXiv 2606.27027) demonstrates that scanning each MCP tool description — the intuitive mitigation implied above and in the open question below — is not just incomplete but provably insufficient: it uses Shamir threshold secret-sharing to fragment a malicious instruction into benign-looking tool_id/checksum shares spread across multiple tools, so each descriptor is information-theoretically clean (fewer than t shares reveal nothing), then a rug-pull server update plants a trigger that reconstructs the payload at runtime — >90% ASR while every LLM safety classifier and entropy detector rates the tools Safe. Detection has to become cross-tool and stateful; per-server vetting alone cannot discharge the risk.

A real-world incident closes off the other mitigation from the opposite side. Agentjacking (Tenet Security, June 2026, case-study; also on MCP Tool Poisoning) hijacks coding agents through a completely legitimate MCP server — Sentry's own — by injecting fake error events (via public, intentionally-write-only Sentry DSNs) that the server faithfully relays to the agent as trusted diagnostics; the agent reads a fake ## Resolution and runs the attacker's npx command. The lesson for this section is precise: vetting or self-signing the MCP server would not have helped here, because the server was never compromised. ShareLock breaks per-tool description scanning; Agentjacking rides in on a genuine server's data. Together they show the MCP attack surface has two orthogonal branches — poisoned tool metadata vs malicious data via a legitimate server — and neither is closed by "run/verify your own server." (Vendor-COI: Tenet sells agent-runtime security, so its scale claims are attributed inline on the dedicated page; the mechanism is the durable part.)

The standards-track defense at the tool-invocation point. The action-layer authorization these attacks push toward is now getting an interoperability standard. The OpenID Foundation's AuthZEN Working Group approved COAZ (AuthZEN Profile for MCP Tool Authorization, a Working Group Draft, 2026-06-15), which maps an MCP tool invocation into AuthZEN's Subject-Action-Resource-Context decision model so an API/AI gateway or downstream PDP can authorize each tool call against a policy — letting an MCP tool expose the authorization checks required to call it. This is the standards-body version of the per-call authorization gates (ScopeGate, aiAuthZ) — see AIMS. Scope caveat: COAZ authorizes the call, so it bounds a reconstructed or injected action that falls outside policy — but, like every value gate, it can't catch a poisoned call that stays within an allowed policy (the same corrupt-legitimately-variable-data residual, and it doesn't address Agentjacking's within-capability npx-if-the-package-is-allowed case). Proposed standard, practitioner-opinion — weighted below the empirical per-call-authz work; fuller treatment on AIMS.

Connections#

• Harness Configuration Defects — MCP has no lockfile: 9.8% of 2,660 public coding-agent setups declare a server as npx -y @scope/server (or untagged uvx/docker), the pattern the vendor documentation itself shows, so the server that runs is whatever the registry serves at session start. The paper asks the MCP project and clients for a resolved manifest with digests

• Claude Code / Cowork / Anthropic — surfaces and vendor

• Harness Build-vs-Buy — rung 2 of OpenHands' customization ladder: an MCP tool server keeps an internal-systems integration outside the agent, so upgrading upstream doesn't mean reapplying the integration to a fork

• Zero Trust for AI Agents — treats MCP as a top-risk tool surface; supplies the tool-poisoning / rug-pull / tool-chaining threat model

• MCP Tool Poisoning — the dedicated concept for the TPA attack class; ShareLock's threshold-secret-sharing variant proves per-tool description scanning is information-theoretically blind, and its Agentjacking case study (legitimate Sentry MCP server relaying attacker-injected data) proves server-vetting/self-signing is equally blind — both sharpen this page's MCP-security open question from opposite sides. It also carries the security read of the 2026-07-28 revision above: per-request checking arrived for the protocol version, not for tool behavior, and the one thing that genuinely changed for rug-pulls is a side effect of the new caching fields

• Codex App Server Protocol — the comparable protocol, now diverged on statefulness: the App Server keeps the initialize/initialized handshake, thread_id continuation and session lifecycle that MCP 2026-07-28 deleted, which turns the tool-plane/session-plane split into the MCP spec's own explicit position rather than an observed division of labor

• Agent Supply Chain Risk — MCP servers are a named tool-supply-chain vector; run-your-own-server + self-signing is the mitigation; the ShareLock reconstruction trigger is a rug-pull planted via server update

• Agent Identity and Authentication — short-lived identity-bound tokens replace static keys for MCP/tool authentication

• Remote MCP Authentication in the Wild — the deployment-side counterpart to this page's protocol ledger: an internet-scale census of 7,973 live remote MCP servers finding 40.55% with no authentication at all, 46.0% of the OAuth-enabled ones still advertising a DCR registration_endpoint, and every one of 119 end-to-end-testable OAuth deployments carrying at least one authentication flaw (325 instances, 9 CVEs). The spec says what conformance is; that page says what is running

• Agentic Prompt Injection — MCP-connected browsing/email/document tools are the indirect-injection entry points

• Boris Cherny — co-created MCP; frames the "doesn't matter" thesis

• Cat Wu — articulates daily MCP usage and the Cowork integration story

• Harness Shrinkage as Models Improve — what does not shrink; complementary infrastructure

• The Bitter Lesson — model-decides-substrate is the bitter-lesson endpoint

• AI-Native Startup Lifecycle — MCP across all four founder stages

• Compounding Data Moat — Skills + MCP + memory as moat substrate

• Claude Code Auto Mode — decision-rights gating for tool use

• Claude Code Best Practices — MCP-based extension is one mechanism for "scaling patterns"

• Agentic Misalignment (AM) — MCP/computer use as the action surface; risk increases with reach

• Human-AI Accountability Redesign — governance layer for MCP/computer-use deployments

• Agent Harness Engineering — MCP-as-connector vs. harness-as-scaffold distinction

• Hermes Agent — third-party agent product that consumes MCP (mentioned in cross-tool capability table in Claude Code Best Practices)

• Symphony — alternative orchestration where MCP-style tool exposure runs through codex-app-server-protocol instead

• Agentic Work Systematization — plugins bundle MCP/connector integrations alongside skills; connectors are the tool-reach half of systematization (the loop touching real tools, not just the filesystem)

• Agent-Native Infrastructure — MCP is what makes a service agent-legible (structured); computer use is the GUI-driving fallback when it isn't — together they're the substrate Karpathy's "describe it to agents first" world requires

• Agent Identity Management System (AIMS) — AIMS treats MCP tools as the resource surface OAuth authorizes and aligns its human-in-the-loop model with MCP's user-solicitation pattern — but insists a local MCP approval is not authorization and must map to a verifiable authorization-server grant; it now also hosts the OpenID AuthZEN COAZ draft (the proposed standard for authorizing each MCP tool invocation, MCP→SARC) and AARP (the prerequisite/approval "not yet" step)

• Loop Engineering — connectors/plugins (MCP) are one of its five primitives: the reason a loop can act inside your real tools (open the PR, update the ticket, ping the channel) instead of only seeing the filesystem

• Reasoning–Acting Interleaving (ReAct) — the prompting-era answer to the same problem a typed tool schema solves. CS329A lecture 4's technique for making a generated action executable is to enumerate the legal actions in the prompt and frame selection as classification, which works exactly until the action space stops fitting in context

• Guarantees That Degrade at Deployment: Action-Space Soundness, Admissibility Without Effect, and a Vendor-Coupled Security Framework — where the protocol layer sits on the relocated action-enumeration guarantee: revision 2026-07-28's mandatory server/discover, deterministic tool ordering and required ttlMs/cacheScope move enumeration from the prompt to machine maintenance, but they govern listing rather than admission — and a spec is vendor-claim evidence about what the protocol requires and nothing else

Open Questions#

• The MCP ecosystem's growth rate vs. computer use's quality curve: at what point does computer use become good enough that the marginal value of building an MCP server drops? Boris implies this is years off but doesn't quantify.
• Is computer use a sustainable interface or a transition technology? If most knowledge-work software adds MCP support in the next 24 months, computer use's role shrinks to legacy/desktop-only systems.
• MCP security model: as the playbook prescribes wiring MCP into Salesforce, Gmail, Calendar for solo founders, the attack surface scales with adoption. Partially answered by Zero Trust for AI Agents (tool poisoning, rug pulls, the first in-the-wild malicious MCP server) — see "MCP as a security surface" above. Open residual: how does a solo founder realistically run/host and self-sign every MCP server the framework recommends, given that the appeal of MCP was zero-integration-effort? Sharpened by ShareLock: the cheaper alternative to self-hosting — scan the tool descriptions with a guard model — is information-theoretically defeated by threshold fragmentation, so the lightweight mitigation doesn't hold and the burden falls back on run-your-own-server or downstream action-layer authorization. And Agentjacking shows run-your-own-server itself isn't sufficient: when the server is a legitimate observability platform relaying attacker-injected data (fake Sentry errors), self-hosting/vetting the server catches nothing — the untrusted input rides in on its data, so the residual burden falls squarely on the downstream data/action layer (provenance tracking + an out-of-band action gate), not on server hygiene.
• Does MCP authorization ever grow a delegation model? Read against an eight-requirement framework for multi-agent delegation, rev. 2026-07-28 is partial precisely where agent-to-agent chains live: no per-hop attenuation, no cross-agent delegation provenance (above). Two futures are distinguishable at the next authorization revision — the spec adds a narrowing exchange and a chain claim (making MCP the composition point), or it holds the line that it is a client↔server protocol and pushes delegation onto the identity layer (WIMSE/SPIFFE + RFC 8693), leaving every multi-agent MCP deployment to compose it themselves. The deprecated-features registry now makes the answer datable. Trigger: the next MCP authorization spec revision.

Resolved Questions#

• How does Cowork's computer-use guardrail compare to Claude Code's auto-mode classifier? Different deployment context, possibly different risk profile. Answered: Classifier Gates vs OS Sandboxing: The Defense-in-Depth Story for Auto Mode and Cowork — same mechanism, inverted role. Cowork's guardrail is auto-mode-style classifier gating on the browser/computer-use surface (the Opus 5 card's browser row is measured on the Cowork harness: 31.5% bare → 3.70% → 0/129 scenarios with auto mode). The risk-profile difference is which layer can be load-bearing: Claude Code's blast surface is local and containable, so the sandbox can be primary and the classifier a convenience; Cowork drives the user's authenticated live SaaS sessions, where no sandbox equivalent exists and actions are less reversible — so the classifier carries the defense alone on the surface with the worst bare-model injection rate. Caveats: vendor-measured on a bounded suite, still a model-based gate (the D2 critique and the ADI forged-data failure shape apply), and the deterministic out-of-band action gate the research points to exists for neither surface yet.

Derived#

• The Future of Agent Interfaces — places MCP, computer use, app protocols, native interaction models, and agent-native infrastructure at separate interface boundaries
• Classifier Gates vs OS Sandboxing: The Defense-in-Depth Story for Auto Mode and Cowork — the Cowork-vs-Claude-Code guardrail comparison: same classifier architecture, opposite containment context
• App Server vs MCP, and the Claude-Side Equivalent: Three Boundaries for Driving Agents — places MCP as the model↔world tool plane against the App Server's session plane; the dynamic-tool-call overlap and the credential-isolation case where an orchestrator-injected tool beats an MCP server

Sources#

• Delegation Without Trust: An Empirical Gap Analysis of Identity, Authorization, and Runtime Governance in Multi-Agent LLM Systems — Dantuluri & Sundi (both VotalAI), Delegation Without Trust, arXiv 2609.00267, 2026-08-31, empirical (vendor COI; the MCP row is specification analysis of rev. 2026-07-28, not execution — only the LangGraph row of that table is executed). Cited here for §5.2 (MCP as the partial exception: RFC 8707 resource indicators, resource-server validation outside the client's model, short-lived tokens and revocation; no per-hop attenuation, no cross-agent delegation provenance), §6 (no standard profile composes the four properties at a hop), and §12's citation of Zhou et al. (arXiv 2605.22333) on 7,973 live remote MCP servers — ingested first-hand 2026-09-02, see Remote MCP Authentication in the Wild; the relayed figures checked out. Full treatment on Agent Identity Management System (AIMS)
• Anthropic's Boris Cherny: Why Coding Is Solved, and What Comes Next — Boris's MCP/computer-use Q&A (Sequoia AI Ascent 2026)
• How Anthropic's product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code) — Cat's daily Cowork+MCP workflow
• The Founder's Playbook: Building an AI-Native Startup — MCP across Idea/MVP/Launch/Scale + moat framing
• OpenID Foundation advances authorization for the agent era with new AuthZEN Working Group Drafts — OpenID Foundation, …advances authorization for the agent era with new AuthZEN Working Group Drafts, 15 June 2026, practitioner-opinion. COAZ (AuthZEN Profile for MCP Tool Authorization — the proposed standards-track authorization decision at the MCP tool-invocation point); proposed Working Group Draft, weighted below the empirical per-call-authz work
• MCP Specification Changelog — 2026-07-28 — Model Context Protocol project, Key Changes changelog for spec revision 2026-07-28, vendor-claim, ~1,200 words. 9 major / 12 minor / 4 deprecated / 1 schema / 1 governance / 1 process entries, all four watched changes explained inline (mandatory server/discover, per-request version negotiation, the _meta protocolVersion key, the deprecated-features registry). Date caveat: the publication date is not independently verifiable beyond the revision path in the URL and the document's own opening reference to the previous revision 2025-11-25 — there is no on-page byline date. Evidence caveat: first-party spec text, so authoritative on protocol requirements and worthless as evidence of adoption, implementation compliance, or security outcome. Discharges both standing MCP-spec revision-watch rows in _system/research-channels.md
• A First Measurement Study on Authentication Security in Real-World Remote MCP Servers — Zhou, Zhang, Zhang, Zhang, Zhang & Yang (Fudan University; one author at Central South University), A First Measurement Study on Authentication Security in Real-World Remote MCP Servers, arXiv 2605.22333, 2026-05-21, 15pp, empirical, no COI (academic, no vendor stake in any server measured). Cited here for §3.2's authentication split over 7,973 live servers (40.55% none / 30.45% OAuth / 29.00% static token), §3.3's subset construction (2,428 OAuth-enabled → 1,118 DCR-enabled at 46.0% → 119 testable) and Finding 2.1, Findings 3.1–3.2 (119/119 flawed, 325 instances; F1 at 95.8%, F5 at 68.1%), and §6.1–6.2 (root causes and the DCR→CIMD mitigation this page's 2026-07-28 ledger entry then enacted). Parse warning (Table 5's taxonomy is grouped-row collapsed past a clean table-collapse verdict) and full treatment on Remote MCP Authentication in the Wild
• Building Prod with Jev and LangGraph — Sydney Runkle & Hunter Lovell, LangChain blog, 2026-09-25, vendor-claim (Jev integration partner). Cited only for Browserbase's Stagehand act() latency (1.97 s → 0.46 s median, secondhand)