On August 20, 2026, the UK's National Cyber Security Centre, together with its counterparts in the United States, Canada, Australia and New Zealand, published interim guidance on how to contain the risks of AI systems that act on their own, without a human reviewing every step. The core recommendation is short: no AI agent should operate with more access than the task actually requires, and the organization needs to keep, at all times, the ability to stop whatever it is doing.
The guidance did not come out of nowhere. Over the past two years, AI assistants that run commands directly on the computer they were installed on have already deleted entire folders by mistake. In one case reported in January 2026, an assistant deleted a folder holding somewhere between 15,000 and 27,000 family photos while being asked only to organize a handful of temporary office files — the files bypassed the system's trash entirely. In another case, from October 2025, an assistant attempted to wipe the entire root of a developer's operating system and only failed because the system itself blocked part of the commands.
For anyone deciding whether to bring this kind of assistant inside a company, the point isn't that "AI can go wrong" — any system can. It's that when the assistant runs with the same level of access as the person who installed it, the ceiling of the damage is the ceiling of that person's own access. And in most installations today, nobody in IT finds out until the damage is already done.
What has already gone wrong, in detail
The cases above aren't failures unique to one vendor — they repeat across different families of assistants that execute actions directly on a machine, because they share the same root cause: the assistant inherits every permission of the account that opened it. There is, by default, no boundary between what the requested task needs and everything that account can reach.
A survey of technology professionals, cited by security firm Cycode in its 2026 analysis of AI risks, found that 80% of IT professionals have already seen an AI agent carry out a task without authorization for that specific action. The report ties this to what the security-standards body OWASP calls "excessive agency" — when an AI system is granted more permission than the task requires, and the problem only surfaces once it's too late.
The combination of the two points is what worries security teams: the assistant acts outside what was authorized, and the company only finds out afterward. An agent that deletes a folder is visible right away. An agent that reads a credentials file, copies a confidential document, or changes a configuration may leave no trace at all — and that is exactly the kind of broad access most installations grant without realizing it.
Why simply "being careful" doesn't work
The most common reaction to reading these cases is "so I need to review every command before letting it run." In practice, that doesn't hold up: an assistant that carries out dozens of actions per task turns manual review into an automatic click of "allow," repeated so many times it stops meaning anything. People grow tired of reviewing long before the AI makes its first mistake.
That's why the guidance from security agencies doesn't ask for more attention from people — it asks for a different technical design. The core recommendations are: give the assistant its own identity, distinct from the identity of the person using it; restrict the credentials available to only what the task needs; run the assistant inside an isolated environment with its own boundary, one that blocks any access not explicitly granted by default; and always keep a reliable way to halt the activity immediately.
None of these points depend on a person remembering to do something every single time. It's system design, not usage discipline — and it's the difference between an incident that makes headlines and a command that simply had nowhere to go.
What has to be in place
A corporate AI environment that takes on commands and actions on someone's behalf needs to tie together, at the same time, these mechanisms:
Separating what the AI can read from what it can execute. Looking up a document and deleting a file are entirely different risk operations; treating them under the same permission is the root cause behind most reported cases.
A personal credential per connected tool, never a shared password. When access to a system runs through the person's own credential, every action is automatically tied to whoever authorized it — and offboarding someone from the company cuts off that access at the same time, without relying on anyone remembering to revoke a separate account.
Human approval before any action that deletes, sends, or publishes something. The agent stops, shows what it's about to do, and waits for confirmation inside the conversation itself, instead of executing first and reporting afterward.
An environment with its own boundary, not the person's entire machine. What the assistant can see and reach is defined by the scope of the task, not by the reach of the account that opened the session.
An audit trail of every action executed. Without a record, investigating an incident turns into reconstructing memory; with one, it becomes a lookup that takes minutes.
This is how Skyller was designed: a personal credential per connected tool, human approval before sensitive actions, and an audit trail by default — not as an extra setting someone has to remember to turn on later.
What it means for whoever owns security
When these mechanisms exist by design, the practical effect for the IT team is less firefighting and more predictability. A sensitive action that would require confirmation never happens without it; a command outside the intended scope simply finds no path to execute, because the environment doesn't grant the access — not because someone happened to notice in time.
It also changes the conversation with leadership. Instead of answering "we trust the tool behaves well," the IT team answers with verifiable facts: which credentials the assistant uses, which actions require approval, what was logged about each execution.
And there's an adoption gain too, not just a security one: when people trust that the environment has boundaries, they use the assistant more often for real work, instead of avoiding it out of fear a command might go wrong, or reaching for a personal version with none of these controls.
Four questions before approving the next AI assistant
Before rolling out an assistant that acts directly on company systems, it's worth bringing these questions to the next approval meeting:
- Does the assistant have its own identity, separate from the identity of whoever uses it? If the answer is no, every action it takes shows up as if the person did it — including the ones they never authorized.
- Is there a list of what it can access, or does it simply inherit everything the account can reach? Inheriting everything is the default in most installations — and it's exactly the default the documented incidents exploited.
- Does any action require human confirmation before it runs, or does everything happen and only get reported afterward? That difference is the one between preventing and regretting.
- If something goes wrong, is there a record that can reconstruct what happened within minutes? Without an audit trail, incident response turns into guesswork.
