- The Hacker News reports that employees are connecting personal AI agents to work systems, often without a ticket, and that admin consoles do not list the truly personal ones.
- Unlike a personal device, an agent acts inside company systems in the employee's name, so the useful control is the account, grant and session it uses.
- Leaders should ask whether staff can consent to third-party apps, which agent grants and long-lived keys exist today, and what happens at offboarding.
The new colleague nobody hired
Picture an employee who asks a personal assistant to manage their calendar, read their email and keep their chat threads tidy. The assistant does it well. Then the employee connects it to work. Nobody may file a ticket, and IT may never hear about it.
That is the scenario The Hacker News describes in a report on what it calls Bring-Your-Own-Agent. The report starts from a blunt assumption: staff will link these agents to work systems, approved or not. The argument below is WebPulse's own. The risk is not the software the employee installs. It is the second actor now working under the employee's name.
Why this is not a repeat of BYOD
Bring-your-own-device gave IT something to enroll. A phone or laptop could be registered, scanned and wiped. The Hacker News says a personal agent offers no such handle. It runs on the vendor's infrastructure, or it sits on the employee's machine where it is hard to pick out.
The report adds that the agent's reach matches the employee's reach. Yet most of what it is asked to do uses only a small part of that. The gap between what the agent can touch and what it needs is the exposure.
The lesson here is a change of question. The old model asked which device is touching our data. The new one has to ask who, or what, is signing in as this person.
How an agent gets in
The report lists several routes, and none needs a special process.
The first is OAuth, the permission prompt that lets one app act inside another. An employee approves an agent's request to reach Google Workspace, Microsoft 365 or Slack. Where a tenant lets ordinary users grant such permissions to outside apps, no administrator is ever asked.
The second is a text thread. The report says users of the start-up agent Instinct text it and link a Google, Apple or Facebook account. The agent then acts through whatever services are connected.
The third is saved passwords. Many agents sign in through a browser with an internal password manager. To the company's app, it looks like the employee logging in.
The fourth is API keys and personal access tokens. Unofficial integrations can run on them. Users generate these once, and they can keep working for a long time.
The fifth is the laptop. The report says Meta's Muse gained a Mac app on September 18. With the user's permission it can read files, notes, calendars and email, and users may also grant it Full Disk Access.
Two designs, two blind spots
Where the agent runs changes who holds the keys. Muse works from a dedicated virtual machine, a software computer in the vendor's cloud. A component called Sentinel screens each outgoing request, and the agent never touches the tokens itself.
That sounds careful, but the report points out the catch. Sentinel enforces the user's policy, not the employer's. Corporate session tokens end up on someone else's computer.
Local agents such as OpenClaw flip the problem. Credentials never leave the machine, yet company systems see no difference between the agent and the person.
What is not solved yet
The report is candid about the gaps. Companies still cannot tell whether a username and password sign-in is the employee or their agent. Agent-to-agent communication is unsolved. So is compartmentalizing knowledge, so that a personal agent loses what it learned at work when the employee leaves.
Vendors are adding controls for managed deployments, such as corporate versions of OpenAI's Dots, xAI's GrokBot and Muse. The report says those only work inside a corporate deployment, and that none of the truly personal agents will appear in the relevant admin console.
A caveat on the source: the report closes by pointing readers to Token Security's product. WebPulse has not tested that product, and the advice below does not depend on it.
Questions to put to your team this week
The report cautions against blocking such agents en masse, since employees are learning to rely on these tools. It suggests treating the agent as an outside party that someone else runs. What the company can see is the other side: the accounts, permissions and sessions the agent uses inside its own systems. Four questions follow from that.
First, can employees consent to third-party apps in our tenant today? If yes, who reviews what they have approved? Second, what do our logs show: permissions granted to agent vendors, logins from vendors' cloud address ranges, and long-lived API keys held by clients nobody recognises? Third, when someone leaves, do grants, tokens and sessions end with the account, or outlive it? Fourth, who is the named owner of every non-human identity that touches customer or financial data?
An agent with a clear owner, limited access and an end date is a manageable colleague. An agent with none of those is a stranger holding a key.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: The Hacker News.
