AI assistants and agents now log in, type, and click on people's behalf, and the systems on the other end often can't tell the difference between human and non-human users. Banks are already seeing the consumer version: customers hand their credentials to AI assistants, and banking sites are flooded with automated traffic they can't easily tell from real customers. The workforce version of this problem is next, and it won't be limited to any single industry. Anywhere employees have access to data worth protecting, from hospitals and banks to manufacturers, software companies, and government agencies, AI will be acting with that access.
Most organizations are not yet in a position to see it. That is less a detection problem than a foundation problem: the controls that would make AI-specific detection meaningful are not in place yet. This post breaks down what organizations should have in place now, so the next step, actual detection, is possible.
Security teams already know how to handle a person with access who might move data where it shouldn't go. That discipline is insider threat and data loss prevention: control what gets installed on an endpoint, control where data is allowed to travel, and control who can see what. It is not glamorous, but it works, and most mature security programs have spent a decade building it.
Generative AI reopens that problem. If anyone can install any AI tool on an endpoint, anything that tool can see can be exfiltrated. A browser extension that summarizes a patient chart, a desktop assistant that reads a shared drive, a coding agent pointed at a repository: each one has the same reach as the user who installed it, and none of them went through procurement.
There is also a new layer that DLP was never designed for. Data that goes into an AI tool the company doesn't control should be assumed to be training data. Treat it as effectively public, with no way to get it back. There is no retention policy to enforce and no deletion request that reliably reaches a model's weights.
And it isn't only tasks being outsourced, it's decisions. An unapproved AI acting with an employee's access makes calls nobody approved and nobody can audit: which records to pull, which email to send, which ticket to close. The audit trail shows the employee did it, because as far as every system is concerned, the employee did.
Until the basics are in place, there is nothing for AI-specific security to build on.
1. Pick your tools. Approve and license specific AI products, such as Claude and Claude Cowork, ChatGPT Enterprise, or OpenAI Codex. An enterprise license is what gets you data handling terms, admin controls, and audit logs. "We allow AI" without naming which AI is not a policy.
2. Allowlist the approved tools and block everything else, on endpoints and on the web. Endpoint application control covers installed software. Web filtering and secure web gateway policy cover browser-based tools and extensions. Doing one without the other leaves the more convenient path wide open.
3. Containerize it. Run AI in an isolated environment where IT controls which files, sites, and programs it can reach. The operating system now supports this directly. Microsoft made Microsoft Execution Containers (MXC) generally available in October 2026, with policy that declares exactly which files, network destinations, and applications an agent can access. GitHub Copilot and OpenAI Codex already support MXC, and Claude Code is expected to follow.
4. Give the AI its own identity. Every agent or AI process gets a non-human identity (NHI) that is separate from any person. If an agent runs under the user's own credentials, every log entry it generates is indistinguishable from the user's, and accountability ends there.
5. Keep the agent, its identity, and its access inside the container. The NHI should only work from inside the container, so the agent's credentials can't be lifted and used anywhere else. Windows is moving in this direction: Microsoft says it assigns agents a local ID or a cloud-provisioned identity backed by Entra and attributes all activity from the container to that identity, and its agent workspaces give each agent its own account and its own session, separate from the user's.
6. Link the identity to its human owner and scope it down. Every NHI should trace back to a named person, and its access should be a narrow subset of that person's. Read-only access to this user's email is a reasonable scope. Read-only access to everyone's email, because the service account was easier to provision that way, is not.
7. Make sure only the right human can give the agent orders. A well-scoped agent that anyone can command is still a liability. It's on the enterprise to put controls around the container so that only the authorized user can send instructions into it.
The seven controls enterprises need in place to lock down approved AI, from licensed tools to authorized commands. None of them cover AI sending keyboard and mouse input as the user.
Once all of that is locked down, the easy path that's left is the human input channel: AI acting through the user's keyboard and mouse, under the user's identity, with the user's access.
Allowlists can't fully close this off in remote, hybrid, or VDI environments, which describes most hospitals. An employee can run an unapproved AI tool on a personal laptop and have it drive their work virtual desktop; the virtual desktop only sees keystrokes and clicks arriving from a legitimate session. Or a cheap plug-in USB device, some as small as a watch, presents itself as a keyboard and mouse, and any AI on the other end can drive a fully locked-down laptop. There is no installed software and nothing for application control to block.
Two ways AI gets around a locked-down endpoint: unapproved AI on a personal laptop driving a work virtual desktop, and a small USB device posing as a keyboard and mouse so any AI can drive a managed laptop. Neither installs anything on the work device.
Two terms are worth separating here. Shadow AI is unapproved AI acting as the user. Rogue AI is an approved AI that oversteps by borrowing the user's access instead of using its own scoped identity. Both arrive on the same channel, and both look like the user to every control described above.
At that point, behavior is the only signal left. NIST is working through the same question of how to verify who, or what, is behind a session, and the answer won't come from which tool is installed or which identity is logged in. It comes from whether the input driving the session belongs to your human, or to something that is not a human at all.
That's the signal Twosense's Continuous Authentication Platform reads, continuously and without adding friction to the user's workday.