GC·D4 closed by seating the integrated runtime provider at the conductor’s stand. The structural claim was that the four-voice quartet — red teams, standards bodies, independent auditors, and the integrated runtime provider — performs the runtime governance calculation together, with the provider holding the access required to govern continuously. That dispatch answered who is competent to govern. It did not answer who owns what.

This dispatch is the natural successor to that one. The question it answers is not architectural in the same register. It is architectural in a different register: when the score has been written and the orchestra is playing, who is contractually accountable for which surface? Where does the conductor’s responsibility end and the performer’s begin?

That question is not new. The cloud security industry answered it three different ways between 2008 and 2015. The SaaS vendors of the prior decade inherited the pattern and adapted it as the abstraction moved up the stack. The pattern is now resolving itself again, in the agent wave, with Anthropic, OpenAI, and Google each taking structurally distinct postures — and with the CoSAI AI Shared Responsibility Framework V1.0, approved by the OASIS Open Project’s CoSAI Project Governing Board on May 26, 2026, arriving as the multi-vendor consortium counterpart. The Enterprise Architect’s reading is that the divergence itself is informative — and that the procurement-grade audit instrument none of them has yet specified is exactly the artifact this wave needs.

From Competence to Ownership

GC·D4 and this dispatch ask two different architectural questions about the same harness layer. Confusing the two produces apparent contradictions where there are none.

GC·D4 produced a Competence Map. The question was: who has the structural capacity to do the runtime governance calculation? The answer was four actors, ranked by access. Three voices — red teams, standards bodies, independent auditors — perform indispensable evaluative work but operate on cadences slower than the runtime cadence the harness demands. The fourth voice — the integrated runtime provider — has the structural access required to govern continuously. The Compression is the substrate that makes the fourth voice possible.

This dispatch produces an Ownership Map. The question is different: who is contractually accountable for which surface of the resulting deployment? The answer is two parties — the provider and the enterprise — with a contractual seam between them. The trifecta does not disappear. It distributes across both zones and around the audit surface that crosses them. The framing this dispatch develops — the Harness Shared Responsibility Model — is the Ownership Map applied to the agent harness specifically.

The two models do not contradict. They answer different architectural questions about the same harness. A reader walking from the Competence Map into the Ownership Map is being asked to switch which question they are answering, not which model is true. The cloud security debate evolved exactly this way: the early conversation was about who is competent to secure cloud; the later conversation became about who owns which responsibility. Both questions had honest answers. The progression from competence to ownership is what made cloud governable at enterprise scale, and the same progression is what will govern the harness.

Inside the Ownership Map, the harness itself is the contested surface. The provider does not own the harness in the abstract. The harness is the architectural object that the Shared Responsibility Model resolves. The provider owns the substrate side — choreographic infrastructure, runtime trace enforcement, persistent memory primitives, protocol enforcement, unified policy enforcement. The enterprise owns the deployment side — goal representation, tool manifest, data scope, workload-specific governance, the enterprise-side deployment configuration responsibility. The seam between them is the contractual surface where one zone hands off to the other.

This calibration matters because it preempts the most likely misread. Provider ownership of harness substrate is not provider monopoly with enterprise compliance. It is a genuine structural division between two parties who each own distinct architectural surfaces. The matrix that documents that division is what the procurement conversation requires.

How the Cloud Wave Resolved the Question, Three Ways

The cloud security industry did not converge on a single Shared Responsibility Model. It converged on a category of models — three structurally distinct postures from the three dominant providers, each reflecting its broader market position and architectural commitments. Treating that divergence as informative is the first move an EA makes when reading the agent wave.

AWS introduced the formal framework around 2011 and has held the line since. Security of the cloud is the provider’s responsibility — the hardware, software, networking, and facilities that run AWS Cloud services. Security in the cloud is the customer’s responsibility — determined by the AWS Cloud services they select, scaled to the amount of configuration work each service requires. Three control categories sit underneath the binary: Inherited, Shared, and Customer Specific. The service-tier observation is foundational: as customers move from IaaS to PaaS to abstracted services like S3 and DynamoDB, the provider absorbs more of the substrate-side burden and the enterprise retains a smaller deployment-side surface. The one constant: responsibility for customer data is never transferred to AWS regardless of service degree.

Microsoft Azure adopted the AWS structural pattern and operationalized the service-tier shift more explicitly. Microsoft’s published model spells out IaaS, PaaS, SaaS, and on-premises as four distinct shared-responsibility configurations with the responsibility line moving at each tier. Two refinements matter for the EA reading. First, the service-tier shift is treated as a primary operational variable, not a footnote. Second — and this is load-bearing — identity, client device security, and data protection remain customer responsibility regardless of service model. No tier of service transfers responsibility for these three surfaces. Microsoft has separately extended the framework into AI services with explicit language naming “managing prompt security” and “mitigating prompt injection risks” as customer responsibility. The line model is being carried forward into the AI wave, with the deployment-side responsibilities expanding to include agent-specific surfaces.

Google Cloud took the third path. Google published a Shared Responsibility framework and then explicitly extended it with Shared Fate as an architectural critique of line-drawing itself. The critique is sharp and worth quoting precisely. Phil Venables, then Google Cloud’s CISO, characterized the AWS-style model this way: “That clearly is contractually and legally correct, but it doesn’t, in our opinion, embody the right philosophical approach for security.” The published Shared Fate page goes further: “We will not be the delineators of where our responsibility ends and where yours begins. Instead, we share in the outcome of your security transformation.” Operationally, Shared Fate is a set of provider-side commitments: secured landing zones, opinionated blueprints, secure-by-default infrastructure foundations, and risk-sharing instruments — including cyber insurance through Google Cloud’s Risk Protection Program. The seam is treated as a configuration surface the provider must actively populate, not a line the customer is told to defend.

Three resolutions. Same underlying architectural problem. The structural insight all three share: neither party can absorb full responsibility. The disagreement is on how the seam should be documented and what the provider’s role across the seam should be. AWS and Azure say document the line. Google says erase the line and build secure-by-default infrastructure that makes the line less load-bearing.

The SaaS vendors of the prior decade inherited this debate and adapted it as the abstraction moved up the stack. The provider’s substrate-side responsibility grew to include application logic, the data model, workflow primitives, and identity surfaces. The customer’s deployment-side responsibility narrowed to configuration, access control, customization, and integration. The seam moved with the abstraction. The matrix kept its structural form. Not every SaaS vendor published a framework with AWS’s rigor — many operated in a product-first posture with the matrix implicit in product design — but the structural pattern was the same.

The agent wave is the third instance. The form is different — agent deployment has structural features neither cloud nor SaaS had, including autonomous tool use, persistent memory, multi-agent coordination, and harness-mediated runtime — but the necessity of the matrix is the same. The EA who has lived through both prior waves recognizes the shape of this one immediately. What follows is the empirical reading of where the three major model providers stand right now.

Where Three Model Providers Stand Today

Each of the three major model providers has taken a structurally distinct posture on agent shared responsibility. The divergence is exactly the kind the cloud wave produced at the same maturation moment.

Anthropic is in the AWS-2009 position. On April 9, 2026, Anthropic published Trustworthy Agents in Practice, filed under Policy, with the underlying technical framework submitted to NIST’s Center for AI Standards and Innovation. The paper extends Anthropic’s August 2025 framework for safe and trustworthy agents — five principles of human control, alignment with user expectations, security, transparency, and privacy — into an operational architecture with four named components.

The four components, in Anthropic’s own language: the Model is the intelligence that makes tasks possible, the product of training. The Harness is the instructions and guardrails the model operates under. Tools are the services and applications the model can use — email, calendar, expense software. The Environment is where the agent runs and which files, websites, or systems it can access. Anthropic’s structural claim is direct: “A well-trained model can still be exploited through a poorly configured harness, an overly permissive tool, or an exposed environment. This is why the safeguards we and others build need to account for them all.” Three of the four components are explicitly the deploying organization’s responsibility.

This is the standards-absorption move executed at the model-provider layer. Publish the structural framework before any standards body imposes one. Claim the vocabulary. Define what “shared responsibility” means in this domain. The closing call in the paper is unambiguous: “this is the kind of infrastructure no single company can build alone.” Anthropic created MCP as an open protocol and donated it to the Linux Foundation’s Agentic AI Foundation specifically because, in their framing, open protocols allow security properties to be designed into the infrastructure once rather than patched together one deployment at a time. The framework is the most architecturally rigorous of the three. It has one structural feature an EA cannot ignore: it names what is owned at each layer but does not document the seam — the contractual surface where provider responsibility hands off to enterprise responsibility. This is the same gap the AWS Shared Responsibility Model had in 2010, and the gap that produced years of enterprise misconfiguration breaches.

OpenAI is in the product-first position — the posture that characterizes much of the SaaS vendor pattern of the prior decade. OpenAI Frontier launched February 5, 2026 as an end-to-end enterprise platform for building, deploying, and managing AI agents — agent identities with scoped access, audit logs, monitoring, agent suspension authority for admins. Workspace Agents in ChatGPT followed on April 22, 2026 with RBAC controls, Compliance API integration, and detailed admin governance for agent configuration, updates, and run history. The operational governance is substantial. OpenAI also publishes extensive safety and capability documentation — system cards, the Preparedness Framework, Model Spec 2.0, the safety and alignment doctrine. What it has not published is a shared-responsibility architecture comparable to Anthropic’s four-layer framework or Google’s documented inheritance — a structural allocation of responsibility between provider and deploying organization at the agent-deployment layer. “Shared responsibility” appears in OpenAI’s safety doctrine only in the societal register — humans, organizations, and society sharing responsibility for AGI safety — not in the contractual provider/enterprise register that defines who owns which surface of an agent deployment.

The framework is implicit in product design. Enterprises must reverse-engineer the shared responsibility model from product behavior. Fidji Simo, OpenAI’s CEO of Applications, characterized Frontier this way at launch: “Frontier is really a recognition that we’re not going to build everything ourselves.” The advantage of the product-first posture is operational speed. Ship product, learn, iterate. The cost is contractual ambiguity: enterprises negotiating with a product-first provider have no documented matrix to take into procurement conversations. They build their own from product surfaces, which means every enterprise produces a slightly different read, and procurement becomes a per-account exercise rather than a category conversation.

Google is in the cloud-inheritance position. The Gemini Enterprise Agent Platform Shared Responsibility documentation, most recently updated May 11, 2026, opens by explicitly inheriting from the parent framework: “Security is a shared responsibility… Learn more about Shared responsibilities on Google Cloud.” Google’s published responsibilities are infrastructure protection (physical, network, application security), platform security (access controls, security monitoring, incident response), and compliance with applicable industry standards. Customer responsibilities are monitoring for security incidents and reporting them, and complying with use-case-specific regulations.

This is the cleanest cloud-inheritance execution of the three. The advantage is regulatory and contractual continuity. Gemini Enterprise Agent Platform inherits Google Cloud’s existing audit infrastructure, compliance attestations, contractual surface, and Shared Fate commitments. Enterprises already operating on Google Cloud do not need a fresh shared responsibility conversation — they extend the one they already have. The cost is conceptual: Google’s published agent shared responsibility reads as “cloud shared responsibility, extended” rather than as a fresh architectural answer to a fresh architectural problem. The agent-specific structural surfaces — harness, tools as MCP and A2A protocols, environment as runtime substrate — are not separately named at the matrix level. They are absorbed into the existing categories.

There is an architectural irony worth naming. Of the three providers, Google operationally has the most sophisticated agent-specific governance machinery in production — Agent Identity with SPIFFE-formatted IDs, Agent Gateway as a runtime enforcement point, Model Armor for policy inspection, integrated IAM, semantic governance policies, and detailed audit logging. The platform is more substantively agent-aware than what the shared responsibility documentation suggests. The framework is generic. The product is specific. For an EA reading procurement-grade artifacts, the published matrix is the contractual surface — and Google’s published matrix carries less agent-specific detail than its product warrants.

CoSAI is the multi-vendor consortium move — the agent-wave counterpart to the Cloud Security Alliance’s work in the cloud wave’s maturation. On May 26, 2026, the OASIS Open Project’s Coalition for Secure AI published the AI Shared Responsibility Framework V1.0 under Workstream 2 (“Preparing Defenders for a Changing Cybersecurity Landscape”). It is structurally different from the three single-vendor postures in three ways an EA should note. First, it is a five-layer scaffolding rather than four: AI Business & Usage, AI Information, AI Application, AI Platform, AI Model Supply Chain. The additions over Anthropic’s four are deliberate — Business & Usage at the top to handle industry-specific regulatory compliance, Model Supply Chain at the bottom to handle training data governance and foundation model lifecycle. Second, it specifies eight personas (Agentic Platform and Framework Providers, Application Developer, Data Provider, AI System Users, AI System Governance, Model Provider, AI Model Serving, AI Platform Provider) all mapped to ISO/IEC 22989:2022, providing standards-grounded vocabulary for accountability assignment. Third, it overlays the layers onto a Cloud Operating Models Responsibility Matrix spanning AI-SaaS, AI-PaaS, Agent-PaaS, and IaaS — addressing the procurement question at the cut where cloud governance was already resolved.

The participation list matters as much as the framework. Akila Srinivasan of Anthropic is the Technical Steering Committee Co-Chair (alongside J.R. Rao of IBM). Reviewers include David LaBianca (Google), Jason Garman (Amazon), Asmae Mhassni (Intel), Arthur Saputkin (Meta), Marina Zeldin (Dell), and contributors from Cisco. This is the standards-absorption move executed at the consortium level rather than the model-provider level. Anthropic is participating in both — its own four-layer framework and the multi-vendor five-layer framework — which is the strongest standards-absorption posture of any actor in the wave. CoSAI itself acknowledges the participation asymmetry: its Appendix A.1 states explicitly that “AWS has no published AI SRM as of publication date,” and its contributor list does not include an OpenAI representative.

Four reference points now. Three single-vendor postures and one multi-vendor consortium framework. Same architectural problem. The divergence is exactly the kind the cloud wave produced — AWS published the formal framework, Microsoft adopted and extended with service-tier nuance, Google critiqued and proposed Shared Fate as successor, the Cloud Security Alliance assembled the multi-vendor consensus position. The agent wave is producing the same kind of four-way distribution at the same kind of moment in the wave’s maturation.

The question for enterprise architects is not which framework is right. The four are operating in complementary registers: Anthropic’s four-layer model is the most architecturally rigorous single-vendor scaffolding; CoSAI’s five-layer model is the most institutionally legitimized multi-vendor scaffolding; Google’s posture inherits two decades of cloud-governance continuity; OpenAI’s posture is operational sophistication ahead of architectural articulation. The question is what the procurement-grade audit instrument should look like, given that the layer scaffolding is already published in two forms. That instrument is what no provider and no consortium has yet specified. That instrument is what this dispatch produces.

The Harness Shared Responsibility Matrix

Two layer scaffoldings are now published. Anthropic’s four-layer model (Model, Harness, Tools, Environment) is the most architecturally rigorous single-vendor structure and is most directly aligned with the agent-architectural cut this dispatch is making. CoSAI’s five-layer model (AI Business & Usage, AI Information, AI Application, AI Platform, AI Model Supply Chain) is the most institutionally legitimized multi-vendor structure and is most directly aligned with the enterprise-architectural cut a procurement conversation traverses. The dispatch does not re-litigate either split. It overlays four column dimensions onto the agent-architectural scaffolding to produce what the procurement conversation requires, in a form that traces cleanly onto either layer model.

The four columns are:

Provider substrate side — the architectural responsibility that cannot be replicated at the enterprise perimeter. The agent-wave equivalent of “security of the cloud.”

Enterprise deployment side — the configuration discretion that cannot be performed by the provider on the enterprise’s behalf. The agent-wave equivalent of “security in the cloud.” This is the enterprise-side deployment configuration responsibility zone.

The Responsibility Seam — the contractual surface that must be documented at each layer. Secure-by-default contributions the provider should make. Documented defaults. Audit and trace requirements that bridge the two sides. This is where Google’s Shared Fate insight matters most: the seam is not a line, it is a configuration surface the provider must actively populate.

Trifecta Distribution — where red teams, standards bodies, and independent auditors sit relative to each layer. The Competence Map’s trifecta distributes across both zones and around the audit surface.

The matrix operationalizes Anthropic’s framework at the procurement level and traces cleanly onto CoSAI’s. It uses Google’s Shared Fate insight to populate the seam column with active provider responsibilities, not just hand-off boundaries. It uses Microsoft Azure’s data-and-identity-always-with-customer principle to anchor the deployment side. It uses AWS’s three-control-category structure to inform the trifecta distribution column. CoSAI’s matrix takes a different cut — cloud operating models on one axis (IaaS, AI-PaaS, Agent-PaaS, AI-SaaS) and five enterprise architecture layers on the other — which is the right cut for the cloud-procurement question. The Harness Shared Responsibility Matrix takes the agent-architectural cut — the four layers Anthropic names, overlaid with the four responsibility columns the procurement conversation needs. The two matrices coexist. None of this is a correction of the source frameworks. The dispatch’s contribution is the column dimensions and the seam treatment, not the row scaffolding.

The Seam Audit Surface and What Enterprises Should Demand

That is the structurally novel governance question this wave introduces. The matrix in the previous section names the four layers and the seam between them. It does not yet specify how a failure that crosses those layers gets reconstructed after the fact — which is the question that decides whether the contract is enforceable.

Consider a failure chain agentic incident response has to handle as one event:

Which log proves where the failure occurred? The document ingestion sits in the enterprise zone. The memory contamination sits at the provider’s persistent memory primitive. The planning step sits at the model layer. The tool execution sits at the harness-tool boundary. The action sits in the enterprise environment. No single zone’s audit trail reconstructs that event. The trace has to cross the seam — repeatedly — to be useful.

This is the question cloud never had to answer at this level because cloud incident response is more linear: the breach happens at one layer, the trace sits at that layer, the responsibility is at that layer. Agentic incident response requires cross-zone trace because the failure modes cross zones structurally. The mechanism that makes that trace operational is the Seam Audit Surface, and its operative property is cross-zone trace continuity — the audit capability that crosses provider zone and enterprise zone and remains coherent across the handoff. Who maintains it? Who has access? Who is accountable for its integrity? Who can subpoena it under regulatory scrutiny? These are the questions enterprises should now be demanding answers to.

This is also where standards bodies and independent auditors play their most distinctive agentic role — not as evaluators of one zone or the other, but as the audit surface that verifies the seam itself. The trifecta does not disappear when the architectural question shifts to ownership. It distributes, and it concentrates at the seam.

CoSAI’s framework anticipates a piece of this. Its Appendix A.7 specifies evidence requirements per layer — governance, technical, operational, assessment, and attestation categories — and its agentic-specific evidence section names reasoning chains, tool/API invocations, inter-agent communications, human override events, and boundary violation attempts as required telemetry. This is the most architecturally serious published evidence taxonomy in the wave, and it lays the groundwork for what cross-zone reconstruction requires. What it does not yet name — and what the dispatch contributes — is cross-zone trace continuity as the structurally distinct mechanism: the audit capability that traces across provider zone and enterprise zone and remains coherent across the seam itself, treated as an architectural object with its own integrity, access, and accountability properties. The Seam Audit Surface is that object. CoSAI’s evidence taxonomy is the layer at which the Seam Audit Surface gets populated; the Seam Audit Surface is the cross-layer mechanism that gives the evidence its forensic value when the failure crosses zones.

The honest accounting is that the seam in the agent wave will always be less clean than the seam in the cloud wave. The provider trained the model, defined the harness contract, created the tool protocol, and specified the environment defaults. Even where responsibility nominally sits with the enterprise — local instructions, tool selection, deployment goal, identity policy — the provider’s architectural reach shapes what the enterprise can configure. The line is structurally more porous because the provider’s reach is structurally broader. The matrix must acknowledge this rather than pretend the cloud parallel resolves cleanly.

The matrix tells you what to own. It does not tell you what to measure. The Seam Audit Surface specifies the mechanism — cross-zone trace continuity — but it does not specify which signals at which layer constitute decision-grade observability. That question is the natural successor to this one. Enterprises that build the matrix without building the measurement surface are exposed in a different register: they know who is responsible, but they have no instrument that tells them whether the responsibility is being discharged.

Practical implications for procurement, in the same register as GC·D4’s “which conductor’s score to sign” but operationalized: Does the provider publish a shared responsibility matrix at the layer-by-layer level, or only at the platform level? Are the defaults documented per layer, or only at the product level? What audit continuity exists across the seam, and what contractual commitments back it? Can the trace be subpoenaed under regulatory scrutiny, and on what terms? Where does provider responsibility for secure-by-default end, and enterprise responsibility for secure-by-configuration begin?

The substrate is the work. The matrix is necessary but not sufficient. Enterprises that demand the matrix but do not develop internal capacity to populate the enterprise-side columns are still exposed. The matrix is the floor of the procurement conversation, not the ceiling.

The Honest Accounting

Two waves resolved this question. The third is resolving it now. The shape recurs because the structural problem recurs.

What this wave inherited from cloud is the matrix — at the provider level (Anthropic, Google) and at the consortium level (CoSAI, the OASIS Open Project’s multi-vendor framework). What this wave has not yet built is the Seam Audit Surface. Anthropic published the most architecturally rigorous single-vendor framework and identified the structural claim — model security alone is insufficient because the harness, tools, and environment all carry attack surface. Google extended its cloud Shared Responsibility framework into the agent platform and inherited the contractual continuity of two decades of cloud governance. OpenAI shipped substantial operational governance through Frontier and Workspace Agents without publishing a shared-responsibility architecture comparable to the others — operational sophistication ahead of architectural articulation. CoSAI assembled the multi-vendor consortium position with five enterprise architecture layers, eight ISO/IEC-mapped personas, and the most architecturally serious published evidence taxonomy in the wave.

What enterprises should now demand is the matrix and the audit surface across the seam. The framework documents who owns what. The audit surface tells you whether the ownership was discharged. Together they make the contract enforceable. Apart, they leave enterprises holding responsibility they cannot prove was satisfied.