Enterprise security teams are waking up to a new reality: employees are bringing AI agents into work systems without formal approval. These “personal assistants” connect via OAuth, saved credentials, API keys, or directly from users’ devices. They act with corporate-like access, often under the user’s identity, creating risks that traditional IT governance doesn’t cover. Today, it’s not a question of if these agents exist in your environment—it’s how visible and controllable they are.
How Casual Use Becomes Corporate Risk
The trend is evolving fast. Agents that started as tools for time management, messaging, or home use are now tapping into employees’ work accounts—email, calendars, file storage. OAuth-based connectors are the primary method: employees grant permissions like they would to any app without notifying IT. Sometimes agents use saved passwords or personal access tokens. Others run locally on the user’s machine with broad access.
Several products are leading this shift. OpenAI’s Dots is built for enterprise-style deployment, offering specialized agents under identity and credential control. Meta’s Muse, mostly consumer-focussed, now supports connections to business tools like Slack and Vercel. Then there are cross-boundary agents like Instinct, which operates via texts, or open-source options like OpenClaw that run locally. Some, like the cloud-based variants, can function with guardrails; local agents pose harder identity-based risks.
Governance Doesn’t Yet Match Reality
Vendors are introducing features to support managed deployments—enterprise dashboards, credential profiles, connectors. But these controls only apply when an organization explicitly claims the agent under a corporate plan. Personal agents outside those programs bypass those controls entirely. IT consoles today often don’t show or manage these rogue agents—making them effectively invisible despite their access.
The contrast is clear between agents running locally and those operating in vendor clouds. Cloud-based agents, if built securely, can isolate credentials and enforce outbound checks. Local agents blur the lines: they use the same credentials as employees, making it impossible for security tools to tell agent from human behavior.
What Companies Should Do Now
The emerging consensus: instead of trying to ban agents outright, organizations should treat them like external identity holders. That means discovering and mapping which agents are connected, who owns them, what they can access, and ensuring they’re cut off if the employee leaves or when their role changes. Key levers include an inventory of OAuth grants, unknown API tokens, login patterns from vendor cloud IP ranges, and endpoint data that shows automaton behavior.
This approach also demands rightsizing permissions—limiting what agents can do inside corporate tools, removing “owner’s all” privileges. Offboarding becomes more complex: sessions, tokens, linked accounts need revoking just as you would with any device or app. Identity, not device or location, needs to be the trusted control plane.
Your future agent-proof blueprint likely comprises four pillars: discovery, attribution, minimal access, and offboarding. You also need the ability to distinguish human logins from those made by agents, manage inter-agent communication, and control knowledge retention across agents. These features are nascent but critical for closing the gap between theory and risk.
What this means is clear: organizations must assume AI agents are already operating inside. Blocking them may be unrealistic—and counterproductive—but governing them intelligently is now unavoidable. Security teams that adopt identity-first controls today will be more resilient when regulation, compliance, and insider threats finally catch up.
