Three Independent Bodies, One Architecture: The 2026 Convergence on Admission Control for Agentic AI

Algis Dumbris • 2026/05/10

In the first four months of 2026, three independent security bodies published major frameworks for agentic AI security. The bodies did not coordinate. They cite no shared draft. Their organizational missions, jurisdictions, and audience overlap only in the broadest sense: an enterprise CISO, a governance regulator, and an open security community publish into different channels, with different review processes, against different audiences. And yet, when their frameworks are read side by side, the three converge on the same architectural requirement at the agent-tool boundary.

The framework from Forrester is AEGIS — Agentic AI Enterprise Guardrails For Information Security — published in April 2026. It is a six-domain analyst framework aimed at CISOs making investment and architecture decisions about agentic AI. The framework from OWASP is the MCP Top 10, published in beta in early 2026. It is a vulnerability framework specifically scoped to MCP, modeled on the OWASP Web Application Top 10 that has anchored web security investment for two decades. The framework from Singapore’s Infocomm Media Development Authority is the Model AI Governance Framework for Agentic AI, published in January 2026. It is the world’s first national governance framework for agentic AI, with regulatory weight in the second-largest financial center in Asia-Pacific.

Three frameworks. Three audiences. Three independent paths to publication. One architectural conclusion.

What Each Framework Said

Forrester’s AEGIS framework defines six security domains: Governance Risk and Compliance, Identity and Access Management, Data Security and Privacy, Application Security and DevSecOps, Threat Management and Security Operations, and Zero Trust Principles. The Zero Trust domain is where the convergence appears. Forrester names a specific principle for the agentic layer: least agency. The text is direct: “agents should be granted only the minimum capabilities required to complete their specific tasks, revocable at any time, with no persistent access between task sessions.” The framework explicitly positions this as the Zero Trust principle for the agent-to-tool relationship, parallel to least-privilege at the user-to-resource relationship that has anchored access control since the 1970s.

The operational reading of least agency is direct. An agent that has not been authorized for a specific tool cannot use that tool. An agent that has been authorized for a tool retains the authorization only for the duration required to complete the task. The default state is no capability. Capability is granted at admission, scoped to a task, and revoked at task completion. The framework does not describe an implementation; it describes the property the implementation must satisfy.

The OWASP MCP Top 10 arrives at the same property from a different direction. The Top 10’s first three risks are Token Mismanagement and Secret Exposure, Privilege Escalation via Scope Creep, and Tool Poisoning. The framework’s mitigation guidance for each of these names a specific structural defense at the admission layer. Token mismanagement is mitigated by ensuring credentials are not bound to servers that have not been reviewed. Privilege escalation is mitigated by bounding tool capability at admission, not at runtime. Tool poisoning is mitigated by inspecting tool descriptions before they are made available to the agent.

The OWASP framework also names a specific risk that does not appear in the older OWASP web frameworks: MCP09, Shadow MCP Servers. The category captures the production reality that has driven much of the 2026 MCP threat surface — servers that enter the agent’s environment without going through a security review, often as transitive dependencies of other tools, often through developer-installed packages that were not on any inventory. The mitigation for MCP09 is, in operational terms, an admission control gate: a default-deny posture for any server not on an authorized list.

Singapore’s IMDA framework approaches the same architecture from a regulatory direction. The framework — covered at length by Bird & Bird, Baker McKenzie, and Computer Weekly — is the world’s first national governance framework specifically for agentic AI. Its technical control dimension contains a specific named requirement: “controlling access to whitelisted services.” The phrase is short, but its operational implication is unmistakable. A whitelisted service is a service that has been explicitly approved for the agent to use. Any service that has not been whitelisted is, by the framework’s logic, off-limits. The framework establishes accountability requirements for the entire delegation chain in multi-agent systems and mandates technical controls throughout the agent lifecycle, but the foundational mechanism is whitelist admission at the service layer.

The IMDA framework also names the Agent2Agent Protocol explicitly — by name, in the published text — as an example of the inter-agent communication mechanisms within scope. The naming matters because it tells the regulated entity that the governance framework is not abstracted away from the actual protocols their agents are using. A2A is in scope. MCP is implicitly in scope as the tool-layer protocol that A2A-coordinated agents call into. The whitelisting requirement therefore applies at both the inter-agent layer and the tool layer.

The Same Architecture Under Three Names

Each framework names the requirement in its own vocabulary. Forrester calls it least agency. OWASP describes it as the mitigation for Shadow MCP Servers (MCP09) and the structural defense underlying Tool Poisoning (MCP03), Software Supply Chain Attacks (MCP04), and Insufficient Authentication (MCP07). IMDA calls it controlling access to whitelisted services. The vocabularies are distinct, the audiences are distinct, and the publication processes are distinct. The architectural property they describe is the same property.

The property has a precise operational shape. An MCP server, once installed in an environment, does not become callable simply by virtue of being installed. The default state is quarantine — the server is present, its manifest is available for review, its declared tools are visible, but no agent can invoke any of those tools through the gateway until a human admin has explicitly approved the server for use. Approval is a positive act, recorded against an admission database that becomes the authoritative source of truth for what the agent can do. Revocation is also a positive act, also recorded, also enforced at the gateway layer.

This is the architecture that the three frameworks describe. Forrester says it as “minimum capabilities required, revocable at any time, no persistent access between tasks.” OWASP says it as “default-deny admission with manifest review and central inventory.” IMDA says it as “controlling access to whitelisted services with technical controls throughout the lifecycle.” The phrases are different. The architecture is the same.

The convergence is what makes the conclusion load-bearing. A single framework saying this would be one analyst’s recommendation. Two frameworks saying it would be a recurring theme. Three independent frameworks — from a US analyst firm, an international open security community, and an Asia-Pacific regulator — saying it within four months of each other, without coordination, is something different. It is the security industry independently deriving the same answer from three different starting points: enterprise risk management, vulnerability research, and national governance. Each starting point produces the same architecture because the architecture is the structural answer to the underlying problem.

What “Independent” Convergence Means

The independence of the three frameworks is the part of this story that deserves named emphasis, because it changes how the conclusion should be read.

Forrester’s AEGIS was developed by an analyst firm whose principal customers are enterprise CISOs and security executives. The framework’s commercial purpose is to inform the spending and architecture decisions those customers make. AEGIS exists because CISOs were asking the question and Forrester saw the question as urgent. The 63% statistic that Forrester reports — sixty-three percent of organizations lack AI governance policies — is the demand-side measurement that drove the framework’s publication.

OWASP’s MCP Top 10 was developed by a community of open-source security researchers and contributors, anchored by Vandana Verma Sehgal and the OWASP project structure. The framework’s purpose is to give vendors, developers, and security teams a shared vocabulary for the most important MCP-specific risks. OWASP’s review process is public. The contributor list is public. The framework’s design follows the established OWASP Top 10 methodology, which has been refined over more than two decades against the web vulnerability surface.

IMDA’s Model AI Governance Framework for Agentic AI was developed by Singapore’s national regulator for infocomm and media. The framework is a regulatory document, with the weight of national governance behind it. Singapore’s role as the second-largest financial center in Asia-Pacific means the framework will influence the procurement and deployment decisions of every regulated financial institution in the region. The framework was published with coverage from the major international law firms because it is the kind of regulatory action that triggers compliance reviews across multinational firms.

These three frameworks were not assembled in coordination. They cite no shared draft. They reference different incident corpora. Their authors come from different professional communities. The analytical paths from “what should we do about agentic AI?” to “default-deny admission at the tool layer” are, in each case, internal to the framework’s own reasoning. That three independent paths converged on the same answer is the part of this story that distinguishes it from the usual industry-publication noise.

The pattern is one that recurs in security history at moments when an architectural answer becomes legible to multiple communities at once. The convergence on the certificate authority model in the late 1990s was a similar moment — academic researchers, browser vendors, and standards bodies arrived at compatible positions from different starting points. The convergence on Zero Trust in the mid-2010s was another such moment. In both cases, the convergence preceded the broad commercial deployment by a few years; the architecture was named by multiple bodies before the tooling matured to deliver it at scale.

The 2026 convergence on admission control for agentic AI has the same shape. The frameworks are in place. The vocabulary is being normalized — least agency, MCP09 Shadow Servers, whitelisted services. The implementations exist, but the deployment has not yet caught up with the framework requirements. The next eighteen months are the period in which they will.

What This Means for an Enterprise Building on MCP Today

For an enterprise that has agentic AI in production or in pilot, the three-framework convergence translates into a small set of architectural questions that can be asked of any current MCP deployment.

The first question is whether the deployment has a default state for newly-installed MCP servers, and whether that default state is “callable” or “quarantined.” The Forrester, OWASP, and IMDA frameworks all imply that the answer should be quarantined. If the actual answer for a given deployment is “callable as soon as installed,” that is a gap against all three frameworks at once. The gap is closed by introducing a gateway that imposes the default-deny posture between the agent and the tool layer.

The second question is whether the deployment has an admission record — a single, queryable artifact that records, for each MCP server in the environment, who reviewed it, when, against what criteria, and what tools were approved as a result. Forrester’s revocability requirement, OWASP’s MCP08 Audit and Telemetry category, and IMDA’s lifecycle technical controls all assume the existence of such a record. Many current deployments do not have it; they have partial inventories scattered across ticketing systems, configuration files, and developer wikis. Consolidating to a single authoritative admission record is the operational change that satisfies all three frameworks’ audit assumptions.

The third question is whether the deployment can revoke a previously-approved server quickly, without human-out-of-loop manual intervention. Forrester’s “revocable at any time” language is specific. OWASP’s mitigation guidance for several Top 10 categories assumes the operator can pull a server out of the environment when the threat profile changes. IMDA’s lifecycle controls require the same. A deployment that lacks a single revocation switch — that has to chase down configurations across multiple agent environments to remove a server — is, by all three frameworks’ implicit assumption, undefended in the case where revocation is needed.

These three questions are the operational reading of the three-framework convergence. An enterprise that can answer “yes” to all three has the architecture the frameworks describe. An enterprise that cannot has gaps that will appear in security questionnaires, RFP responses, and regulatory audits over the next twelve to eighteen months as the frameworks move from publication into procurement language.

The Architecture That Was Already Running

The reason this convergence is worth a long-form analysis is not that the conclusion is novel. Default-deny admission control is not a new idea in security. It is the same architectural principle that underlies firewalls, access control lists, certificate-based authentication, and most of the rest of network security as it developed between 1990 and 2010. What is new is the application of the principle to the agent-tool boundary, and the speed with which three independent bodies have converged on it as the structural answer.

The MCPProxy project’s quarantine-by-default architecture was built in 2025, before any of the three frameworks were published. The architecture was not designed to satisfy AEGIS, the OWASP MCP Top 10, or the IMDA framework, because none of them existed when the design was settled. It was designed against the operational problem the frameworks would later name: the absence of a default-deny posture at the agent-tool boundary, the resulting class of incidents that the absence enabled, and the structural defense that closes the gap.

That the frameworks converged on the same architecture afterward is, in some sense, the easier story to tell. The frameworks did the work of naming the requirement. The implementation was waiting for the naming. The next phase — the phase that the three-framework convergence kicks off — is the phase in which enterprises begin asking their existing MCP deployments to satisfy the frameworks, and discover whether the architecture is in place or whether it has to be built. The work to do is straightforward when the architecture is already running. It is more difficult when it has to be retrofitted.

Three independent security bodies arrived at the same conclusion within four months of each other. The conclusion is that the agent-to-tool relationship requires a default-deny admission gate. The architecture has a name and a working implementation. The 2026 convergence is the moment the rest of the industry catches up to it.