Enterprise Adoption2 min read

Personal AI Agents Must Be Managed at the Login, Not the Device

By , Senior AI ConsultantPublished

Companies handled employees' own phones by controlling the device, but a personal AI agent has no device, so the control moves to the permission an employee gives it to read work email.

Meta launched its personal agent Muse in the United States in September, and OpenAI followed at the end of that month with Dots, agents that keep working in the background. Both are built to act for one person: read the email, check the calendar, fill in the form, make the booking. An employee who finds that useful at home will want it at work, and the work inbox is one tap away.

The phone rules came from the phone

With phones, a company could manage the thing itself. It could demand a passcode, keep work mail in a separate app and erase that app if the phone was lost. That is why the iPhone story ended well for most companies: once IT said yes with conditions, the conditions had somewhere to attach.

The people who pushed hardest then were executives, who had the most sensitive mail and the least patience for IT. The same will happen now. The first people to connect a personal agent to work email will be the ones with the most email worth reading, and a ban will move that use out of sight, not stop it.

An agent has no device to manage

Here is how an agent gets into a company mailbox. The employee opens the agent's app and taps "connect email". The company's own sign-in page then asks whether this app may read and send mail on the employee's behalf. The employee agrees. From then on the agent's vendor holds a token, a kind of digital key, that works from the vendor's servers, far from any company laptop.

That key is the real exposure. A security researcher showed in September that malware already running on a Mac could steal the token for a Muse account, which opens whatever the owner has connected to Muse. Meta has patched that flaw, but the lesson holds for every agent: whoever holds the key inherits the access, as we wrote when an agent carries the keys of whoever set it up.

The permission screen is where a company can act

That moment of clicking "allow" is the one place the company sees the agent arrive. In Google Workspace, an administrator can set the default so that outside apps asking for more than basic sign-in details are blocked. In Microsoft 365, the administrator can turn off employee consent and route requests to an approval workflow, so an employee who wants an agent asks, and someone answers. Answering yes to an agent with narrow access can take minutes.

Narrow access is easy to build. A recruiter who wants help with interview scheduling does not need to hand an agent her whole mailbox. She can give the agent its own address and copy it on scheduling threads, so it sees only what she sends it. She gets most of the benefit, and salary offers and candidate files stay out of its reach.

The setting has limits. It stops agents that connect by permission. An agent that drives a web browser can use an employee's own login if the employee gives it the password, and no setting sees that. That needs a plain rule that work passwords never go into an agent, and the rule will hold only if the company also offers an approved agent that is good enough that nobody is tempted.

That is the larger lesson from phones. Companies that said no lost the argument and the visibility. Companies that said yes quickly, on terms they could enforce, got both the benefit and the control. With agents the terms live in a settings page, so saying yes on the company's terms can start there.

Share this

STAY INFORMED

Get AI intelligence like this delivered to your inbox.

Free forever · Unsubscribe anytime


You May Also Find Valuable