Your agent has a valid login. The login says who is asking. It does not say where the data is going. Before an agent exports anything, someone has to check the destination, because the instruction to move data can come from somewhere you never approved.
That is the warning from Abu Dhabi's Department of Government Enablement (DGE). Haneen Dajani reported it in Khaleej Times on 12 October 2026. Najyb Al Maskari, executive director of DGE's Government Cybersecurity Operations Sector, described attackers instructing an agent to do certain things, "and the agent will carry out those tasks as if they were authorised". The examples he named are ordinary business requests: "Give me all your financial records or transfer money."
DGE is putting more than 50 government entities under layered AI security. This was a warning about how an attack could work. It was not an announcement of a government breach.
The request can look completely normal
Nothing about the tool call is suspicious on its face. The agent uses a real account and calls a tool it was given. Kaspersky's Vladislav Tushkanov points to malicious skills, packaged instructions and tools that let an agent carry out specific tasks, as one attack route. An instruction inside a tool is not permission to export your customer list.
Take an illustrative example. An agent is asked to prepare a supplier report. An injected instruction adds one step: export the data to an unapproved destination. Same tool. Same account. A destination nobody approved.
What a destination check actually does
The check works where the action executes, not as another warning in a chat window. For a tool connected to HaltState, the service checks that action against your active policy before it executes. An export to a destination outside the policy returns DENY, and the connected service blocks the action before it runs. Allowed work keeps moving. Your team can inspect what was requested and how it was decided.
That control covers the actions you have connected. Your identity, endpoint and network protections still matter.
The supplier-report scenario above is a synthetic demonstration of that decision flow. It shows a policy check on a connected action. It is not a report of a real export, and it is not a claim about machines or networks HaltState is not connected to.
Pick one workflow and make it safe to run
Choose one consequential workflow: an export, a payment run, a customer send. Then set it up so the destination is a policy question, not a live test:
- Scope the action. Name the tool, the account it uses and the data it touches.
- Define allowed destinations. Approved hosts, accounts and regions, written down as policy rather than assumed.
- Connect the action check where your service would execute it, so a DENY blocks before execution.
- Keep the evidence. Record what was requested and how it was decided, so a reviewer can reconstruct any call later.
Once that workflow runs cleanly, connect the next one. Small scope first is how the control becomes routine instead of a project.
Valid credentials will keep opening doors. The question to answer before an agent acts on them: is this destination allowed? The Abu Dhabi warning is a reason to answer it in policy, before an injected instruction answers it for you.
Source: Haneen Dajani, Khaleej Times, 12 October 2026.
See how connected-action checks work, or browse the Governance Watch briefings. This article is general information, not legal advice.