Cross-Boundary AI Agent Governance: Why Single-Organisation Controls Break When Agents Go Multi-Org

By Tahir Mahmood, Co-founder & CTO, OpenBox · Last updated 14 October 2026

In brief: Cross-boundary AI agent governance addresses the governance challenges that arise when AI agents interact across organizational or platform boundaries. The World Economic Forum’s May 2026 playbook defines three deployment context tiers, each requiring progressively stronger mechanisms for agent identity, authorisation, auditability, and accountability. Governance controls designed for a single organisation do not automatically extend to higher-tier deployments and need deliberate redesign as deployment context changes.

The Single-Organisation Assumption: When It Holds and When It Breaks

Many existing AI agent governance controls are designed around a single context: agents operating within one organisation’s identity boundary, under internal accountability structures, within a known set of regulatory obligations. That design assumption is a reasonable starting point for a large share of current deployments. It becomes insufficient on its own once an agent’s effective authority or execution path crosses a boundary those controls were not built to govern.

What Single-Organisation Governance Relies On

Single-organisation AI agent deployments can draw on governance conditions that many enterprises already have in some form. Internal identity and access management (IAM) infrastructure controls who and what can access which systems. Internal accountability structures can assign ownership for agent behaviour. Data classifications, where they exist, govern what information agents can read, write, or transmit. A regulatory context that is well understood simplifies which compliance requirements apply.

It is worth distinguishing established enterprise IAM capability from agent-specific governance maturity: having IAM infrastructure does not by itself mean an organisation has defined agent-specific accountability, delegation policy, or complete data classifications for what its agents do. The Agent Capability and Authorisation Profile (ACAP), introduced by the World Economic Forum and Capgemini in their May 2026 report AI Agents in Action: A Playbook for Trusted Adoption, Authorisation and Scaling, describes Level 1 single-organisation deployment this way: “Agents operate within internal systems and identity frameworks. Governance can use existing identity and access management (IAM) and internal controls” (WEF, Section 1.5, p. 11).

Internal governance is easier to apply when identity, authority, and execution all remain within control boundaries the organisation can define and enforce. That condition is not guaranteed by single-organisation ownership alone: an internal agent can still depend on an external model provider, third-party APIs, SaaS tools, or externally hosted MCP servers, each of which sits outside the organisation’s own IAM boundary even though the agent itself is internally owned.

The Moment It Breaks

The governance model becomes insufficient at a specific trigger point: when an agent begins to interact with a system outside the organisation’s own IAM infrastructure. This is not a single kind of boundary. It is useful to separate at least four distinct dimensions, since crossing one does not necessarily mean crossing the others:

·         Organizational boundary: the agent interacts with a system, service, or agent controlled by a different legal entity.

·         Platform boundary: the agent operates within infrastructure or an ecosystem it does not control, even if the counterparties are internal.

·         Technical boundary: the agent's execution path crosses into tools, APIs, or MCP servers governed by someone else's configuration and controls.

·         Regulatory boundary: the agent's actions become subject to a different jurisdiction's rules, which can happen with or without an organizational boundary being crossed.

A vendor API and a customer API may sit under the same regulatory jurisdiction even though they cross an organizational boundary. Conversely, a single multinational organisation can operate across several regulatory jurisdictions without any external organisation being involved at all. Treating one boundary as a proxy for the others leads to governance gaps in either direction.

When any of these boundaries is crossed, the internal governance assumptions that applied inside it no longer carry over automatically. The organisation’s IAM does not control external systems. Its accountability structures do not automatically extend to another organisation’s agents. Its data classifications may conflict with an external party’s data handling rules. Its regulatory assumptions may not hold for the jurisdiction governing the other side of the interaction.

Vendor integrations, customer-facing agent deployments, B2B API interactions, and platform marketplace scenarios are credible and increasingly common examples of this pattern. Enterprises are moving from internal agent pilots toward these cross-boundary scenarios, and the governance question is becoming more frequent as a result. Organisations should treat the crossing of any of these boundaries as a trigger to reassess their governance model rather than assuming their internal controls travel with the agent.

The Three Deployment Context Tiers for Enterprise AI Agents

The World Economic Forum’s May 2026 playbook defines three deployment context tiers that classify AI agent deployments by the organizational and platform boundaries they cross (WEF, Section 1.5, p. 11). Each tier requires progressively stronger governance mechanisms, and organisations should assess their deployments against these tiers before assuming their existing controls are sufficient. The WEF frames this as organisations segmenting “deployment contexts by risk and assurance level” rather than as a progression every deployment must pass through in sequence; an organisation may deploy directly at Level 2 or Level 3 without first operating at Level 1.

Level 1: Single-Organisation Deployment

Per the WEF: “Agents operate within internal systems and identity frameworks. Governance can use existing identity and access management (IAM) and internal controls” (Section 1.5, p. 11). In practice, a single-organisation deployment does not automatically guarantee one identity framework or one regulatory context; its agents may still depend on external model providers or services. The regulatory context should be confirmed for the actual systems, data flows, and jurisdictions involved, rather than assumed to be singular by default.

Level 2: Multi-Organisation, Single-Platform

Agents interact within a controlled ecosystem governed by shared platform rules. Examples include a marketplace with embedded agents, a SaaS platform that mediates agent interactions between organisations, or a platform-managed vendor relationship.

The WEF describes governance at this tier as depending on “transitive trust mediated through platform-enforced standards” (Section 1.5, p. 11). The platform serves as a trust intermediary, enforcing standards that both parties’ agents operate under. This is a useful mechanism, but it has two limits worth stating plainly. First, transitive trust is only as strong as the platform’s actual enforcement: if the platform’s governance standards are weak, incomplete, or inconsistently applied, the mediated trust relationship does not compensate. Second, operational responsibility being distributed across the platform and the deploying organisation does not by itself establish shared legal liability or contractual accountability; that allocation needs to be made explicit in the platform agreement, not assumed from the fact that a platform is mediating the interaction. The applicable legal and regulatory position for a Level 2 deployment also cannot be inferred solely from platform mediation; it depends on the actual parties, processing activities, and data locations involved.

Level 3: Multi-Platform, Cross-Boundary Interaction

Agents interact across organisations and platforms. The WEF describes this tier as requiring “stronger mechanisms for identity, authorisation, auditability and compliance” because, as the report puts it, agents interact “without a central authority” (Section 1.5, p. 11). The absence of a central authority does not mean no shared trust infrastructure can exist: federated identity, agent registries, contractual arrangements, and agreed trust frameworks can all provide shared mechanisms even without a single coordinating party. What Level 3 requires is that organisations establish this infrastructure deliberately, since it will not be supplied by a platform the way it is at Level 2.

This is the tier where emerging identity and authorisation standards, discussed below, are most directly relevant, and where AI agent governance practice is least mature across the industry.

The Tier Escalation Recommendation

A central recommendation from the WEF framework: when an agent deployment moves from a lower tier to a higher tier, its governance should not simply be assumed to carry over unchanged. The WEF frames this as organisations needing to “segment deployment contexts by risk and assurance level” (Section 1.5, p. 11), which implies reassessing authority boundaries, oversight mechanisms, and the ACAP itself whenever deployment context changes. The report does not mandate a specific redesign procedure; the practical recommendation is to treat a tier change as a prompt to re-evaluate authority, oversight, and control coverage, not to assume a well-functioning Level 1 governance model will hold once agents begin interacting with external parties.

Deployment Context Tier Reference Table

This table is OpenBox's synthesis of the WEF's deployment context tiers combined with additional architectural considerations; it is not a verbatim reproduction of the WEF's own table and should be read as operational guidance rather than a mandatory checklist.

The Non-Additive Authorisation Principle: A Design Rule for Multi-Agent Pipelines

The WEF states a specific rule for multi-agent pipelines: “In multi-agent pipelines, authorisation is non-additive: a downstream agent operates under the intersection of its own ACAP permissions and those of the agent that invoked it. An orchestrating agent cannot delegate authority it does not itself hold” (Section 1.5, p. 11).

What This Rule Is, and Is Not

This is best understood as a conservative authorisation design principle that an architecture must deliberately enforce, not as a property that every multi-agent implementation automatically has. Expressed simply, the intended effective permission set is the intersection of the caller’s permissions and the callee’s permissions. That model is useful when permissions have compatible, precisely defined semantics and the system is explicitly built to enforce delegation constraints at each handoff.

It does not automatically follow that a sub-agent is barred from a system its orchestrator cannot access, regardless of configuration. A sub-agent may hold its own independent credentials, have direct service access, or operate under its own separately authorized identity, in which case its actual authority depends on the credential model, the delegation chain, resource-server enforcement, and the specific policies in force, not solely on the orchestrator's permissions. Enterprise architects designing multi-agent pipelines should treat the non-additive intersection as the governance target to design and enforce, not as a guarantee that comes for free from using a multi-agent framework. This has direct implications for how authorisation propagation is designed in practice.

The Buyer-Vendor Authorisation Conflict

The WEF report illustrates the cross-boundary dimension of this problem with a specific scenario: “a buyer agent and a vendor agent acting for distinct organisations may operate under different authority limits or approval rules, creating ambiguity when those authorisations do not align” (Section 1.5, p. 11).

Neither organisation’s internal policy automatically resolves a transaction governed by both. The buyer’s agent may be authorized to approve purchases up to a certain threshold, while the vendor’s agent may be authorized to offer discounts only under different conditions. When these authorisation models conflict on the same action, neither organisation’s individual ACAP resolves the ambiguity on its own.

The WEF is direct about this gap: “While this playbook does not define a universal conflict resolution mechanism, it highlights this as an emerging governance challenge and reinforces the importance of interoperable identity, auditable authorisation records and clear human accountability across trust boundaries” (Section 1.5, p. 11). Organisations need to design around this conflict deliberately, since no off-the-shelf resolution mechanism currently exists.

Emergent Behaviour in Multi-Organizational Agent Systems

The WEF report includes a direct warning about system-level risk in multi-agent deployments: "Governing a multi-agent system is fundamentally different from governing a single agent. A multi-agent system exhibits dynamic emergent behaviour that's greater than, or at least different from, the sum of its parts. As a result, a system could have perfectly certified and guaranteed sub-components yet produce collective behaviour that breaches policies" (Section 1.5, p. 11).

This has a specific governance implication for cross-boundary deployments. When agents from different organisations interact, the resulting system is not simply the sum of two individually governed agents. The interaction dynamics between the agents can produce behaviors that neither organisation’s governance framework, on its own, was designed to prevent. Composing individually certified components does not by itself establish that the resulting workflow satisfies every end-to-end constraint.

The governance response the WEF's framing supports: when designing cross-boundary agent interactions, treat the combined system as a separate governance unit that needs its own risk assessment, rather than relying solely on the certification of each participating component. Multi-agent governance practice needs to account for system-level behaviour that emerges from the interaction itself, in addition to the behaviour of each agent in isolation.

Emerging Technical Standards for Cross-Boundary Agent Trust

Several emerging standards address pieces of the infrastructure requirements for cross-boundary agent governance. This space is moving quickly: two of the four standards below changed in material ways between the WEF report’s publication in May 2026 and this article’s October 2026 update. Organisations should design governance models compatible with the direction these standards are taking, without depending on any single standard achieving universal adoption, and should expect to revisit this section as the standards continue to evolve.

Agent Name Service (ANS)

The Agent Name Service is a proposed mechanism for secure AI agent discovery and interoperability, providing persistent agent identity for cross-organizational use. The original ANS proposal was published under the OWASP GenAI Security Project on May 14, 2025, describing a DNS-inspired architecture using Public Key Infrastructure (PKI) certificates for verifiable agent identity and trust.

As of this writing, the current IETF Internet-Draft is version 01 of Agent Name Service v2 (ANS): A Domain-Anchored Trust Layer for Autonomous AI Agent Identity (draft-narajala-courtney-ansv2-01), last updated April 15, 2026. ANS v2 proposes domain-anchored agent identity verified through a Registration Authority, certificate-based verification tied to DNS domain ownership, and an append-only transparency log for lifecycle events. It defines three verification tiers of increasing assurance. This is an individual Internet-Draft submitted as an Independent Submission with Informational intended status; it is explicitly not endorsed by the IETF and has no formal standing in the IETF standards process. Its current listed expiry is October 15, 2026, which means a revised draft may supersede it shortly after this article’s publication; organisations tracking ANS should check the IETF Datatracker for the latest version before relying on specifics. Status: emerging proposal, actively developed, not an approved standard.

Know Your Agent Operating System (KYA-OS, formerly MCP-I)

This standard was known as MCP-Identity (MCP-I) at the time of the WEF report's publication in May 2026, which refers to it under that name (Section 1.5, p. 11). It was developed by Vouched, an identity verification company, and donated to the Decentralized Identity Foundation (DIF) in March 2026. DIF and Vouched announced the framework's renaming to Know Your Agent Operating System (KYA-OS) on April 22, 2026, shortly before the WEF report's publication, reflecting its applicability beyond the Model Context Protocol specifically; the WEF report's text had not yet been updated to the new name at the time it went to print. It uses Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs) to give agents verifiable identities and tamper-evident, scope-limited delegation credentials, enabling cryptographically secure verification of agents and their human principals without prior coordination between parties. It is now governed by the KYA-OS Task Force within DIF's Trusted AI Agents Working Group. Status: early-stage open standard, under active development, recently renamed.

ANS and KYA-OS are not interchangeable or complete substitutes for one another. ANS v2 centers on domain-anchored identity and a transparency log; KYA-OS centers on agent identity, delegated authority, and credential-based proof mechanisms. Their approaches overlap in places but address different parts of the cross-boundary trust problem.

Agent2Agent (A2A) Protocol

The Agent2Agent protocol is an open standard for agent-to-agent communication and coordination, introduced by Google on April 9, 2025, at Cloud Next and subsequently donated to the Linux Foundation, which launched the A2A project on June 23, 2025. A2A enables agents built on different frameworks to discover each other's capabilities, exchange tasks, and stream results using standard web primitives (HTTP, JSON, Server-Sent Events). It complements MCP, which handles agent-to-tool communication, by providing the agent-to-agent coordination layer.

As of a Linux Foundation press release dated April 9, 2026, the project reports more than 150 supporting organisations, up from more than 50 a year earlier, including AWS, Cisco, Google, IBM, Microsoft, Salesforce, SAP, and ServiceNow, deep integration across Google, Microsoft, and AWS cloud platforms, and active production deployments across industries including supply chain, financial services, insurance, and IT operations. These figures originate from the Linux Foundation as the project’s host rather than from an independent adoption audit, and are presented here with that attribution. Status: available, in active development, adoption reported by the hosting foundation.

OAuth-Based Authorisation for MCP

The Model Context Protocol’s HTTP authorisation profile builds on OAuth 2.1-related requirements to provide scoped, expiring access tokens for remote MCP servers, including PKCE (Proof Key for Code Exchange) and resource-server validation. It was introduced in the MCP specification revision of March 2025 and has been refined through subsequent revisions, most recently the specification dated July 28, 2026.

That July 2026 revision made a material change: it formally deprecated OAuth Dynamic Client Registration (DCR) in favor of Client ID Metadata Documents (CIMD) as the preferred client-registration mechanism, while retaining DCR for backward compatibility under the specification’s lifecycle policy. Organisations implementing MCP authorisation should plan for this transition rather than treating dynamic client registration as the current default. These OAuth-based mechanisms govern access to MCP resources specifically; they are not a complete portable agent-identity or cross-organizational governance standard on their own, and organisations should not treat them as solving cross-boundary identity, delegated authority, or audit evidence requirements by themselves. For more on how these controls fit into a broader governance architecture, see structured authorisation for MCP deployments.

Important framing: These are nascent and evolving standards, and two of the four changed materially within the five months between the WEF report’s publication and this article’s review. Organisations should design governance models that are compatible with the direction of these standards without depending on any single standard achieving universal adoption, and should revisit vendor and protocol choices periodically as the landscape matures.

The Agent Passport Concept: A Possible Tool for Cross-Border Deployments

For global or cross-border use cases, the WEF introduces the concept of an agent passport: “For global or cross-border use cases, concepts such as an ‘agent passport’ may be required to enable agents to present verifiable, machine-readable claims of identity, authorisation and jurisdiction-specific compliance that other systems or platforms can independently validate” (Section 1.5, p. 11).

The agent passport would function as a portable compliance credential. Conceptually, it works the way a professional passport allows a person to present verified identity and travel credentials to authorities in different jurisdictions. An agent passport would allow an AI agent to present its authorisation scope, governance provenance, and jurisdiction-specific compliance claims to external systems.

A critical design distinction: agent passports “carry capability and authorisation claims rather than personal data; identity resolution is handled via reference to authoritative registries” (WEF, Section 1.5, p. 11). The passport attests to what the agent is authorized to do and under which governance framework it operates, not to the identity of the individuals behind it. A passport credential by itself does not establish regulatory compliance or guarantee recognition by another jurisdiction; the receiving system still has to validate the claims it carries and determine independently whether they satisfy its own requirements.

It is also important not to treat the agent passport as a universal requirement for every Level 3 deployment. Level 3, as defined above, is a multi-platform, cross-organizational context; it does not necessarily involve multiple countries or regulatory jurisdictions. An agent passport is best understood as a possible portable credential for use cases that specifically need to exchange independently verifiable compliance claims, particularly where geographic or regulatory boundaries are relevant, not as a default component of every cross-boundary deployment. This concept aligns with broader trends in cross-border AI governance, where the portability of governance evidence across jurisdictions is becoming a practical consideration.

The agent passport is a proposed concept, not an adopted standard or available product. Its development will depend on progress in agent identity standards such as ANS and KYA-OS, cross-border regulatory alignment, and industry adoption of interoperable compliance frameworks.

Governance Requirements by Deployment Context Tier: A Reference Framework

The following framework is OpenBox’s synthesis of governance requirements organisations should evaluate for each deployment context tier; it complements, but is not a verbatim restatement of, either the WEF’s tier model or Singapore’s IMDA framework. The IMDA Model AI Governance Framework for Agentic AI, developed by Singapore’s Infocomm Media Development Authority together with the AI Verify Foundation and launched at the World Economic Forum on January 22, 2026, with an update adding case studies and best practices on May 20, 2026, similarly distinguishes governance expectations by deployment setting, particularly where no single party controls identity, authorisation, and oversight. The WEF report itself cites this framework alongside the ACAP (Section 1.5, p. 11). The IMDA framework does not formally adopt the WEF’s specific three-level classification or mandate agent passports; it complements the analysis in this article rather than independently validating the specific tier model or table below.

Cross-Boundary Governance Readiness Assessment

The following ten questions are an internal heuristic organisations can use to evaluate whether their AI agent governance model is ready for cross-boundary deployments. This is not a validated compliance standard. Some questions apply specifically to Level 2 or Level 3 deployments; where a question does not apply to your deployment’s tier, treat it as not applicable rather than as an automatic gap. Establish which tier applies to a given deployment before scoring it against these questions, and treat the results as a prompt for further risk-based assessment rather than a pass/fail certification.

1.  Deployment tier classification: Have you classified each agent deployment by its deployment context tier (Level 1, 2, or 3), and does your governance model reflect the requirements of the assigned tier?

2.  Boundary awareness: Can you identify every point at which your agents interact with systems, data, or agents outside your organisation’s IAM boundary, including the organizational, platform, technical, and regulatory dimensions separately?

3.  Authorisation model: Does your authorisation model treat the non-additive authorisation principle as a design requirement your architecture actively enforces, rather than assuming it holds automatically?

4.  External agent interaction governance: Do you have governance mechanisms for interactions between your agents and agents deployed by other organisations, including an approach to conflict resolution for misaligned authorisation models?

5.  Platform trust assessment: For Level 2 deployments, have you assessed the governance standards of the platform mediating the trust relationship, and has accountability been explicitly allocated rather than assumed shared?

6.  Portable identity: For Level 3 deployments involving geographic or regulatory boundaries, do your agents carry verifiable, machine-readable identity and authorisation claims that external systems can independently validate?

7.  Cross-jurisdictional compliance: For agents operating across regulatory boundaries, which may or may not coincide with organizational boundaries, have you mapped the applicable compliance requirements and confirmed your governance model satisfies them? (Organisations should seek qualified legal review for jurisdiction-specific compliance determinations; this article does not provide legal advice.)

8.  Emergent behaviour assessment: For multi-organizational multi-agent interactions, have you conducted a system-level risk assessment that accounts for emergent behaviour, rather than relying solely on the certification of individual agent components?

9.  Audit trail interoperability: Can your audit trails be shared with, or validated by, external parties for cross-boundary interactions where that is required?

10.  Lifecycle governance: Does your agent lifecycle governance, including decommissioning and authority revocation, extend to agents operating in cross-boundary contexts?

How OpenBox Supports Cross-Boundary Agent Governance

OpenBox provides runtime governance for AI agent deployments, including risk-based assessment (baselining agents across a set of parameters into trust tiers), policy enforcement through configurable guardrails, and cryptographic verifiability of agent actions through tamper-evident records. Its product materials describe runtime enforcement of identity, authorisation, and policy across agent actions and cross-system interactions, decentralized identity support for agents, and a stated aim of enabling agents to operate within a shared trust ecosystem across teams, partners, and organisations. These are OpenBox’s own product claims; organisations evaluating cross-boundary governance tooling should confirm the specific protocols, deployment environments, and audit-evidence mechanisms a vendor supports against their own requirements before relying on them.

Request a demo to see how OpenBox's capabilities apply to your deployment context.

Frequently Asked Questions

What are the three deployment context tiers for AI agents?

The World Economic Forum’s May 2026 playbook defines three tiers based on the organizational and platform boundaries agents cross. Level 1 covers single-organisation deployments using internal IAM. Level 2 covers multi-organisation deployments within a single platform, relying on transitive trust mediated by the platform. Level 3 covers multi-platform, cross-boundary deployments without a central authority, where organisations need to deliberately establish shared trust mechanisms, consider non-additive authorisation, and coordinate cross-organizational audit trails.

What is the non-additive authorisation principle?

It is a design principle stating that authorisation should not accumulate across agent handoffs: a downstream agent should operate only within the intersection of its own ACAP permissions and those of the agent that invoked it, and an orchestrating agent should not be able to delegate authority it does not itself hold. Architectures need to deliberately enforce this; it is not an automatic property of every multi-agent framework.

What is an agent passport?

An agent passport is a proposed concept from the WEF for a portable compliance credential, intended for cross-border use cases that need to exchange verifiable, machine-readable claims of identity, authorisation scope, and jurisdiction-specific compliance. It is not an adopted standard or available product, and it is not a universal requirement for every multi-platform deployment, only a possible tool where geographic or regulatory boundaries are specifically relevant.

How does emergent behaviour affect cross-boundary agent governance?

When agents from different organisations interact, the resulting system can produce collective behaviour that no single organisation’s governance framework was individually designed to prevent, even if each component agent is well governed on its own. The WEF describes this as the system exhibiting “dynamic emergent behaviour that’s greater than, or at least different from, the sum of its parts.” Organisations should treat cross-boundary agent interactions as a separate governance unit requiring their own system-level risk assessment.

When does an internal AI agent deployment become a cross-boundary deployment?

The governance model becomes insufficient on its own when an agent interacts with a system outside the organisation’s own IAM infrastructure. This can happen across organizational, platform, technical, or regulatory boundaries, and these do not always move together: a vendor interaction may stay within the same jurisdiction, while a single multinational organisation can span several jurisdictions with no external party involved.

Sources

World Economic Forum and Capgemini, “AI Agents in Action: A Playbook for Trusted Adoption, Authorisation and Scaling,” https://www.weforum.org/publications/ai-agents-in-action-a-playbook-for-trusted-adoption-authorisation-and-scaling/, accessed 14 October 2026.

OWASP Gen AI Security Project, "Agent Name Service (ANS) for Secure AI Agent Discovery v1.0," https://genai.owasp.org/resource/agent-name-service-ans-for-secure-al-agent-discovery/, accessed 14 October 2026.

IETF Datatracker, "Agent Name Service v2 (ANS): A Domain-Anchored Trust Layer for Autonomous AI Agent Identity, draft-narajala-courtney-ansv2-01," https://datatracker.ietf.org/doc/draft-narajala-courtney-ansv2/, accessed 14 October 2026.

Decentralized Identity Foundation, "DIF and Vouched Advance Agentic Identity with KYA-OS as International Demand for Open Agent Identity Standards Grows," https://blog.identity.foundation/kya-os/, accessed 14 October 2026.

Google Developers Blog, "Announcing the Agent2Agent Protocol (A2A)," https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/, accessed 14 October 2026.

Linux Foundation, “A2A Protocol Surpasses 150 Organisations, Lands in Major Cloud Platforms and Sees Enterprise Production Use in First Year,” https://www.linuxfoundation.org/press/a2a-protocol-surpasses-150-organisations-lands-in-major-cloud-platforms-and-sees-enterprise-production-use-in-first-year, accessed 14 October 2026.

Model Context Protocol, "Specification Changelog (2026-07-28)," https://modelcontextprotocol.io/specification/2026-07-28/changelog, accessed 14 October 2026.

WorkOS, "How an MCP Client Should Tell Your OAuth Server Who It Is," https://workos.com/blog/mcp-client-identity-dcr-cimd-auth-md, accessed 14 October 2026.

Infocomm Media Development Authority and AI Verify Foundation, "Model AI Governance Framework for Agentic AI," https://www.imda.gov.sg/-/media/imda/files/about/emerging-tech-and-research/artificial-intelligence/mgf-for-agentic-ai.pdf, accessed 14 October 2026.

OpenBox, "OpenBox AI Governance Platform," https://www.openbox.ai, accessed 14 October 2026.

OpenBox, "Blog," https://www.openbox.ai/blog, accessed 14 October 2026.

OpenBox (docs.openbox.ai), "Documentation," https://docs.openbox.ai/, accessed 14 October 2026.