Your AI has your keys: the employee clone problem

Plausible deniability won’t save you when your AI clone goes rogue

Never underestimate the predictability of human ingenuity, especially when it’s motivated by money.

Bolder clients keep telling me the same thing: “We want to treat AI like an employee.” Give it a login. Give it access to the same systems, the same data sources, the same permissions as the person orchestrating it. Let it work autonomously, around the clock, picking up tasks and executing them without someone hovering over its shoulder.

I understand the appeal. It’s the logical endpoint of everything the AI platform companies are building towards. But every time I hear it, the same question nags at me: your employee has judgement, context, institutional memory, and a healthy fear of getting fired. Your AI has none of those things. And you’re about to hand it the keys.

The application layer AI has been looking for

Anthropic recently released CoWork, with plugin support following shortly after. It’s their response to OpenAI’s Apps capability announced back in October 2025. Google are building in the same direction with Gemini extensions.

CoWork lets you automate workflows by combining Claude’s reasoning with system integrations, skills, reference materials, and prompts bundled as plugins. If that sounds like the description of a SaaS product, that’s because it essentially is one. The AI platform companies aren’t just building chat interfaces anymore. They’re building the application layer that AI has needed but hasn’t really found, until now — the App Store moment. The platform that lets you get things done to a standard and at a speed you’re willing to pay good money for.

Some people are calling CoWork and its equivalents SaaS killers. I can see why they’d reach that conclusion. Take Notion. Strip away the workflows, the templates and the custom views. What’s left? A WYSIWYG editor and a database. Would it be all that difficult for an AI platform with plugin support to replicate most of what Notion does, dynamically, without anyone having designed a user interface? The AI reasons about what you need, assembles the right data structures, presents the output in whatever format makes sense for the task. The “application” is generated on the fly.

That’s not a fantasy. It’s the direction of travel. And it means AI platforms are about to inherit all the characteristics of every other platform that came before them.

A pattern we’ve seen before

If you’ve watched any previous technology platform mature, the playbook is depressingly predictable. AI platforms will follow the same arc, because the incentives are identical:

• Freemium honeypots — generous free tiers that shrink once you’re locked in, just like Slack, Dropbox, and every other land-and-expand play before them
• App marketplaces — CoWork plugins and the impending AI app stores will be full of the same tripping hazards as every public marketplace: variable quality, security risks, and data-hungry permissions
• Platform lock-in — your skills, your plugins, your workflow history, your institutional knowledge, all encoded in a format that doesn’t easily port to the next platform
• Aggressive monetisation shifts — the model that’s free today will be gated tomorrow, and the capability you built your workflow around will move to a higher pricing tier
• Data mining and surveillance — plugins will be permissions-hungry, gobbling up data long after the context window that justified the access has rotted to gibberish
• Ecosystem cannibalisation — Facebook cloned Snapchat, Foursquare, and Yelp. AI platforms will do the same to the plugin ecosystem they cultivate, absorbing the most popular capabilities into the core product

This isn’t cynicism. It’s pattern recognition. And it matters because the thing being locked in, mined, and monetised this time isn’t your social graph or your file storage. It’s your operational knowledge and your system access.

Oh, and I missed one — ads! We’ve all seen Anthropic’s Super Bowl ads, right? It reeks of the Mac vs PC advertising feud.

• https://www.youtube.com/watch?v=De-_wQpKw0s
• https://www.youtube.com/watch?v=kQRu7DdTTVA
• https://www.youtube.com/watch?v=FBSam25u8O4
• https://www.youtube.com/watch?v=3sVD3aG_azw

The employee clone

This is where the “treat AI like an employee” instinct gets genuinely dangerous.

When a client gives an AI tool the same access as the human orchestrating it, what they’ve actually created is an employee clone. It piggybacks on the role-based access control of its human counterpart. It can read the same documents, hit the same APIs, access the same databases, and trigger the same workflows. It works 24/7 for its corporate taskmasters, slavishly executing whatever it’s pointed at.

But it’s a clone without judgement. It doesn’t know that the production database should be treated differently to staging. It doesn’t understand that the HR system contains sensitive data that shouldn’t be summarised in a Slack message. It doesn’t have the institutional context to know that sending an automated email to a particular client would be politically catastrophic. It just has permissions.

And the plugins make this worse, not better. Unlike the Apple App Store, I don’t see the AI companies providing much more than an AI-driven sense check when apps and plugins are submitted. There’s an opportunity here for the likes of SonarQube, Wiz, and Snyk to step into the gap, but right now the gap is wide open. A plugin that requests broad permissions to function will get those permissions, because the human approving the request is optimising for capability, not security.

I’ve written elsewhere about comprehension debt, the gap between what your systems do and what you understand about how they do it. The employee clone is comprehension debt applied to permissions and data. You’ve granted access you can’t fully reason about, to a system that can’t reason about it either.

Where are the guardrails?

I keep hoping the next big release from Anthropic or OpenAI will be proper guardrails: LLM-as-a-judge evaluation, PII redaction, fine-grained permission scoping, audit trails for autonomous actions. These capabilities are being integrated into AI gateways and AI firewalls by third parties, and I’m waiting for the foundational model companies to cannibalise this space. But I suspect I’ll be waiting a while longer.

The uncomfortable truth is that security and data privacy aren’t the impediment to AI adoption right now. Capability and features are. The companies building these platforms aren’t incentivised to prioritise governance when the market is rewarding speed and functionality. Governments aren’t getting to the regulations fast enough to change that calculus for enough workloads. And when you consider the scale and pace of change, that should make you nervous.

OpenAI acquired OpenClaw for open-ended agent autonomy. Anthropic are extending agent runtimes to run for hours unsupervised. Google are integrating agents deeper into Workspace. The direction is unanimously towards more autonomy, more access, more time between human checkpoints. Which is exactly where the value lies, and exactly where the risk compounds.

What you can do about it

You don’t have to wait for the platform companies or the regulators. There are things you can do now to prepare for the world that’s coming.

Fine-grained RBAC for AI identities. Stop inheriting permissions from the human operator. Create dedicated AI service accounts with the minimum permissions required for each specific workflow. If your AI agent needs to read from a CRM but not write, scope it accordingly. If it needs access to a dev environment, don’t give it prod. It might sounds obvious, but I bet numerous organisations are accepting the risk to benefit from the short term gains.

Fine-grain data governance categories. The data governance classifications of yesterday may not be fit for purpose today. A new category might be in order, effectively ring-fencing more sensitive data, and stopping a data breach that could have a lasting impact.

Walled-off data sources. Segment your data so that AI tools can only reach what they are allowed to and what they need to. Sensitive HR data, financial records, client-confidential information should sit behind explicit, auditable access gates, not be available to any plugin that asks nicely. Treat data access for AI the same way you’d treat it for a contractor on their first day, not a trusted employee of ten years. That might mean creating purpose-driven AI-centric databases, a small price to pay for peace of mind.

Selective integrations. Not every AI tool needs access to every system. The same AI tool in the hands of a different employee might demand different integrations, or fine-grain RBAC. Evaluate each plugin, each MCP server, each integration on its own merits. What data does it request? What actions can it take? What does it look in the hands of Sharon vs Dave? What happens if it malfunctions? If you can’t answer these questions, delay the integration.

Narrow-band agents over permission-hungry generalists. Here’s a radical thought: don’t build one agent to rule them all. The temptation with tools like CoWork and Claude Desktop is to create a single omniscient agent that reads your email, updates your CRM, deploys your code, and orders your lunch — like giving an intern a master key and a Red Bull and hoping for the best. Instead, consider building a suite of focused, custom agents, each with a narrow band of capability, limited integrations, strict guardrails, and a refined workflow. A CRM agent that can read and update contacts but can’t touch financials. A code review agent that can read repositories but can’t merge. A reporting agent that can query dashboards but can’t modify the underlying data. The narrower the band, the more deterministic the outcomes. You get finer-grained permissions, predictable failure modes, and a far more rational ability to reason about hallucination risk, toxicity, bias, and task drift. When a narrow-band agent misbehaves, you’ve got a contained incident you can diagnose in minutes. When your do-it-all generalist hallucinates with production database access and email permissions, you’ve got a career-defining afternoon. The architectural trade-off is more agents to manage, but each one is simpler to audit, cheaper to test, and easier to kill without collateral damage. That’s not overhead. That’s operational maturity.

AI-specific identity roles. This is the one that most organisations haven’t considered yet. Do we need a dedicated “AI” role in Active Directory, distinct from human roles? A role that carries different audit requirements, different data access policies, different approval workflows? I think the answer is yes. The alternative is that AI actions are logged under human identities, making it impossible to distinguish what a person did from what their AI clone did on their behalf. When something goes wrong, and it will, you need that distinction.

This is an established pattern in identity engineering — called non-human identity (NHI) scoping — and it’s implementable today with standard IAM primitives, without waiting for platform companies to build it for you. The approaches range from simple to sophisticated:

• Dedicated service accounts or API keys — the lowest-friction starting point. Give the AI agent its own credential, clearly namespaced (e.g. svc-ai-agent@org). Every downstream audit log attributes actions to that identity automatically.
• JWT custom claims — add actor_type: "ai_agent" and an agent_id as custom claims to any OIDC/OAuth2 token. Applications and MCP servers can inspect these to apply different logic: tighter rate limits, approval gates, or outright refusal of sensitive operations.
• Separate OAuth2 client with restricted scopes — register the AI agent as its own OAuth client with a constrained scope set (ai:read ai:write rather than user:*). The constraint lives in the token itself; no application-level enforcement needed.
• OAuth 2.0 Token Exchange (RFC 8693) — for delegation chains where the AI acts on behalf of a human. The token encodes both a subject (the human) and an actor (the AI), preserving full attribution through the chain.
• API gateway or proxy layer — intercept all AI traffic and enforce AI-specific policies centrally, without touching upstream applications: rate limits, write-operation approval workflows, anomaly detection.

One active gap worth flagging: most MCP servers today don’t forward caller identity through the tool chain, so attribution can be lost mid-hop. If you’re deploying MCP-integrated agents, identity propagation needs to be enforced explicitly at the MCP server boundary — it won’t happen automatically.

Contribute to and use open alternatives. Where possible, use local models for sensitive workloads. Contribute to open-source tooling. Build skills and plugins that you control and can audit, rather than depending entirely on marketplace offerings you can’t or won’t inspect, especially between updates. The more of your AI capability stack that you own, the less exposed you are when the platform economics shift, and they will shift.

Deploy an AI gateway. An AI gateway is the single most impactful control surface you can deploy, and one of the least understood. Think of it as the API gateway pattern applied specifically to AI traffic — sitting between your users, agents, MCP servers and models. Done well, it gives you centralised visibility and control that you simply cannot achieve at the individual tool level.

Establish an AI platform team. A team dedicated to thinking about the above problems. Auditing tools and use cases, monitoring logs, gathering analytics, measuring AI ROI, refining guardrails, managing the AI gateway, and running evaluations. Someone needs to be running evaluations periodically — testing the tools against the various configurations, between releases and a range of threat.

The pattern is clear

AI platforms are going to follow the same arc as every technology platform before them. The free tier will shrink. The marketplace will fill with AI generated slop. The data policies will creep. The lock-in will deepen. This isn’t a question of if. It’s a question of when, and how prepared you are when it happens. AI companies are busy becoming indispensable, so they can later prise our credit cards from our pockets with enshitification.

The employee clone problem is the more immediate concern. The moment you give an AI tool your credentials and your access, you’ve created an entity that can act on your behalf with none of your judgement. The platforms are building towards more of this, not less. More autonomy, more access, longer runtimes.

None of this means you should stop using AI. The productivity gains are real and the direction of travel isn’t going to reverse. But the teams that come out of this well will be the ones that treated AI permissions, AI governance, and AI identity as first-class architectural concerns from the start, not the ones that bolted on security after the breach.

The pattern is clear. The timeline is uncertain. Start preparing now.