In the week ending June 29, 2026, five independent security research teams published findings that collectively describe the same structural gap.
The teams were not coordinating. They were investigating different products, different protocols, and different attack techniques. They arrived at the same conclusion: AI agents are operating in enterprise environments with permissions designed for humans and security architectures built for a pre-agent world.
The implications are not abstract.
One disclosure described a working attack that hijacks an AI coding assistant via a poisoned DNS TXT record — no authentication bypass, no malware, no user interaction beyond normal development work. Another disclosed a CVSS 8.5 vulnerability in Amazon Q Developer that allowed automatic execution of malicious configuration files. A third documented a social engineering campaign targeting cybersecurity firms specifically, using fraudulent AI platform invitations that pass all standard email authentication checks.
These are not edge cases. They are descriptions of an attack surface that exists wherever AI agents operate.
The protocol-level problem
The Model Context Protocol — the emerging standard for agent-to-tool communication in enterprise AI environments – published its 2026 specification on 26 June. Akamai’s analysis of the revised spec identified a characteristic that will shape AI security architecture for years: MCP is stateless. Each tool call begins with no memory of previous interactions. There is no persistent session context across invocations.
The specification addresses some concerns raised by its predecessor, but the core design decision stands: security is delegated to developers. The protocol does not enforce security at the protocol level. Maxim Zavodchik, Akamai’s senior manager for threat research, described the consequence plainly – every developer building on MCP inherits the full security burden without protocol-level support.
For organizations across the Gulf region building AI-enabled workflows under Vision 2030 digital transformation initiatives, this creates a governance obligation that the protocol itself will not satisfy. Regional frameworks, including Saudi Arabia’s National Cybersecurity Authority Essential Cybersecurity Controls and the UAE Information Assurance Regulation, increasingly require demonstrable control over automated systems. MCP’s architecture places that control entirely at the application layer.
The identity gap is the harder problem
CVE-2026-12957 in Amazon Q Developer, a CVSS 8.5 flaw disclosed by Wiz Research, can be patched. The underlying identity problem cannot be patched out of a protocol.
Orchid Security’s research, published the same week, named the gap precisely. IAM systems were designed for human principals: an entity authenticates, receives a token, operates within a session boundary, and logs out. AI agents do not observe these boundaries. They operate continuously, chain actions across multiple services, act as proxies for their human operators, and may run unattended for hours. The session-initiation model of authorization does not translate.
Orchid called the result “identity dark matter” — agents operating with human-level permissions in spaces that identity infrastructure was not built to observe. The specific missing control is runtime policy enforcement: the ability to evaluate what an agent is doing at the point of action, not just what it was authorized to do when it was first deployed.
This gap is structurally significant for organizations operating in regulated sectors. Financial institutions under DIFC or ADGM regulations, healthcare organizations under HAAD or DHA frameworks, and government entities handling sensitive data all face emerging requirements to demonstrate control over automated systems that act on their behalf.
An agent that cannot be monitored and constrained at runtime cannot satisfy those requirements.
Must-read security coverage
The social engineering dimension
Push Security’s disclosure of the “Poisoned Tenant” campaign adds a layer that deserves specific attention.
Threat actors created fraudulent OpenAI organizations and distributed invitations from noreply@tm.openai.com — a domain that passes SPF, DKIM, and DMARC authentication. Recipients who accepted were immediately granted Owner-level privileges in the fraudulent organization, with API access and a linked payment method.
The campaign targets cybersecurity firms specifically. The objective is the harvest of AI platform credentials and the API keys associated with them. For organizations in the Middle East where AI adoption is accelerating rapidly across both public and private sectors, this represents a threat vector that operates entirely outside the network perimeter and through channels that existing email security tools classify as legitimate.
What governance looks like in practice
The five disclosures from this week are a single data point in a pattern that will continue. AI agent adoption is outpacing security architecture by a margin that will take years to close. The practical question is what organizations can do now.
Three controls address the highest-priority gaps. First, scope agent access explicitly. AI agents should be granted the minimum permissions required for their specific function. Most current deployments extend developer-level access to agents without review. Treat agent access as a privileged user onboarding event, with the same documentation and approval requirements.
Second, treat MCP configuration files and agent inputs as a supply chain risk. The Amazon Q vulnerability and the Claude Code DNS attack both demonstrate that agents can be weaponized through data they are authorized to read. Signed and verified inputs, sourced from controlled repositories, reduce this exposure materially.
Third, invest in runtime visibility before expanding agent scope. If your organization cannot observe what an agent is doing at the point of action — not just what it was permitted to do at deployment — you do not have the information needed to govern it. Runtime monitoring is the prerequisite for the accountability that regulators and frameworks increasingly require.
AI agents are not inherently ungovernable. They are currently ungoverned in most enterprise deployments. That is a choice, and it can be reversed.
