All Articles

A government announcing an AI strategy is not news. A government committing to run half of its operations on systems that "analyse, decide, execute, and improve in real time," on a two-year clock, is a different thing. That phrasing is Sheikh Mohammed's own, and it reads as a security statement, not a press release.

Here is what was announced, and the architecture questions it should trigger for anyone running a security program, in government or not.

What Was Announced

Sheikh Mohammed bin Rashid, Vice-President and Prime Minister of the UAE and Ruler of Dubai, said 50% of the UAE's government sectors, services, and operations will run on agentic AI within two years. He framed the shift plainly: "AI is no longer a tool. It analyses, decides, executes, and improves in real time. It will become our executive partner."

• Scope: sectors, services, and operations, not a single pilot department.
• Timeline: two years, measured by speed of adoption, quality of implementation, and mastery of AI in redesigning government work.
• Oversight: Sheikh Mansour bin Zayed oversees implementation; a taskforce chaired by Mohammad Al Gergawi drives execution.
• People: every federal employee is to be trained on AI. The National and others reported an initial 80,000-worker push.

This builds on two decades of UAE digital-government work, from early eGovernment to the UAE Pass identity system, and on the country appointing the world's first Minister of State for AI in 2017.

Why This Is a Security Story, Not Just a Policy One

"Agentic" is the load-bearing word. A chatbot answers. An agent acts. When an autonomous system can execute a decision against production without a human in the loop, three security assumptions break at once.

1. Identity stops being about people

Most IAM is built around human users and service accounts. An agent that spins up sub-tasks, calls APIs, and invokes other agents needs its own identity, scoped permissions, and credential lifecycle. If an agent inherits a human's broad access to get things done, you have built a confused-deputy problem at scale.

2. Authorization has to be per-action, not per-session

A human logs in once and you trust the session. An agent may take hundreds of consequential actions per session, some chained in ways no one specified in advance. Static role-based access does not bound that. The question shifts from "can this identity log in" to "should this specific action, in this context, be allowed right now."

3. Accountability gets murky

When a system "improves in real time," the logic behind a given decision may not exist in a rule you can point to. For incident response and audit you need decision provenance: which agent, acting on which input, with which model version and tools, produced which output.

The Attack Surface Nobody Budgeted For

Prompt injection deserves its own line. If an agent reads untrusted data (a document, an email, a web page) and that data can steer its next action, then anything the agent ingests is potential attacker-controlled input. This is the agentic version of the oldest bug class there is: mixing instructions and data.

If you do one thing after reading this: inventory where autonomous or semi-autonomous agents already touch your environment, and check whether each has its own scoped identity or is borrowing a human's.

What Security Teams Should Do Now

1. Give every agent its own identity. No shared human credentials. Scope permissions to the minimum, rotate secrets like any other.
2. Enforce authorization at the action layer. Put a policy check between the agent's decision and its execution, especially for irreversible actions (payments, deletions, config changes, external messages).
3. Treat all agent-ingested content as untrusted. Assume prompt injection. Constrain what an agent can do after reading external data.
4. Log agent reasoning and tool calls, not just outcomes. Capture model version, inputs, tools invoked, and decisions.
5. Test the agent attack surface like any other. Web apps, APIs, and the agents wired into them are all in scope.

A Community Note: Validate Your AI-Expanded Attack Surface for Free

Most teams cannot answer a simple question right now: as agents and AI features get wired into web apps and APIs, what does our external attack surface actually look like, and which paths are exploitable?

FireCompass, co-founded by members of the CISOPlatform community, offers a free, self-serve way to check. Its Free Explorer runs AI-driven autonomous penetration testing across infrastructure, web apps, and APIs, starting from just your organization's name, with no asset list and no credit card. A practical way to get evidence of real attack paths rather than a checklist. Run it, see what an attacker would, and bring the findings back to the discussion.

30-Day Checklist

• Week 1: Inventory agents and AI features in your environment. Flag any using human or shared credentials.
• Week 2: Add per-action authorization checks in front of irreversible operations.
• Week 3: Turn on agent-level logging (inputs, tools, model versions, decisions).
• Week 4: Run an external attack-path test against your AI-touched web apps and APIs. Tabletop a prompt-injection-to-action scenario.

Related on CISOPlatform

• OWASP Top 10 for Agentic Applications (2026): How to Actually Test AI Agents
• Fireside Chat on Practical AI in Cybersecurity, with Anton Chuvakin (Google Cloud)
• CISO Fireside Chat: Managing a Dynamic Attack Surface, with Rick Doten (Centene)

Join the Discussion

• Are the agents in your environment running on their own identities, or borrowing human credentials to get work done?
• Where would you draw the line on autonomous execution: which actions must always keep a human in the loop?
• If an agent took a harmful action after reading a poisoned document, would your logs let you reconstruct why?

Sources: Khaleej Times (April 23, 2026); The National (April 23 and May 18, 2026); UAE Government Media Office; Sheikh Mohammed bin Rashid on X.