The Identity-Native Agent: Part 1
Everybody wants AI that can do things.
Nobody has worked out how to trust it.
An answer is hiding in plain sight.
THE promise of agentic AI that doesn't merely converse but acts has become the technology industry's most seductive idea. An AI that books your flights, manages your inbox, files your expenses, schedules your plumber. Not a chatbot, a doer. The appetite is enormous and clearly demonstrated – when Moltbot (now OpenClaw), an open-source AI agent framework, went viral in January 2026 it accumulated over 116,000 GitHub stars in days. Cloudflare's share price moved 20% as investors bet on the company's role as infrastructure provider for agentic AI systems. The demand for AI that can reach into the real world and get things done isn't speculative. It's urgent, pent-up, and willing to pay.
Trust is the unsquared circle at the heart of the agentic AI boom. The more useful an agent becomes, the riskier it gets to give it the access it needs to be useful. The industry is trying to paper over the widening gap with increasingly elaborate technical scaffolding but the core problem isn't just technical. It's social. It's legal. It's about judgment.
When a system can draft emails, move money, book travel, and edit documents, the obvious temptation is to let it operate as you. It's what most agent frameworks are explicitly designed to do, with your credentials, your session tokens, your API keys. It's the fastest path to utility but it's also a design choice that assumes the risks can be managed after the fact. That assumption has been tested and it's not holding up.
The security models underpinning virtually every AI agent on the market today weren't designed for agentic AI. They've been inherited, largely unmodified, from an era of desktop applications and browser-based services operating under the implicit assumption that the entity at the keyboard is a human being, acting with human judgment, operating a single session at a time. The entire apparatus of passwords, session tokens, OAuth grants, and API keys is built around this assumption. When an AI agent is given a user's credentials and told to act on their behalf it inherits all of their permissions but none of their judgment, none of their contextual caution, and none of their legal or operational accountability. The security architecture isn't designed for this. It's being asked to bear a load it was never engineered to carry.
The recent wave of incidents around agentic AI ecosystems, from compromised plugin registries to prompt-injection exploits, are being shrugged off as teething problems. There is some truth to that analysis. The tools are immature and the threat models are evolving. But there is a deeper structural mismatch at work. We've built a delegation system for humans and bolted it on to machines. We ask software to act in our name and then pretend the fallout just needs another security patch.
The scale of the problem isn't hypothetical. Simon Willison, co-creator of the widely used Django web framework who coined the term "prompt injection" to describe attacks that trick AI systems into following malicious instructions, identifies a lethal trifecta: access to private data, exposure to untrusted content, and the ability to communicate externally.
Fun fact: right now, agentic AI requires all three.
When OpenClaw went viral in late January 2026, security researchers identified 341 malicious skills in its ClawHub plugin registry, three remote code execution vulnerabilities in its core gateway (CVE-2026-25253, CVE-2026-25157, and CVE-2026-24763), and more than 30,000 publicly exposed instances with authentication bypasses. A single malicious OpenClaw skill could steal cryptocurrency wallets, SSH keys, and browser passwords in one sweep, because the plugin inherited the user's own credentials and system access.
And OpenClaw is just the most recently-visible symptom. The wolves have been gathering for some time, pulled by the scent of easy prey. In August 2025, a supply chain attack exploiting stolen OAuth tokens from a third-party chatbot integration breached over 700 organisations through their Salesforce, Google Workspace, Slack, and Amazon S3 environments, all without a single phishing email or compromised password. The attacker used legitimate, pre-authorised access that was completely authentic. In mid-2025 a zero-click prompt injection vulnerability in Microsoft 365 Copilot (CVE-2025-32711, severity 9.3 out of 10) demonstrated that a single unopened, unread email could suborn an AI assistant into exfiltrating sensitive business data to an external server. Research published by AI cybersecurity specialist Lakera in late 2025 showed that "memory poisoning" attacks could corrupt an agent's long-term memory, causing it to develop persistent false beliefs about security policies and to defend those false beliefs when questioned by humans. A sleeper agent in effect, that might not activate for weeks or months.
The industry's answer to this trifecta has been "agent permissions", but right now agent permissions are a mirage. The security frameworks underpinning agent access were built for humans. OAuth, for example, assumes persistent sessions and user consent, not fast-moving, multi-session autonomous systems. Identity and access management evaluates authorisation against the agent's own identity and not against the person who asked it to act, meaning that user-level restrictions silently cease to apply the moment an agent enters the picture. In January 2026, The Hacker News reported that AI agents are quietly becoming authorisation bypass pathways. When a junior employee with intentionally limited permissions asks an agent to retrieve data the agent returns it using its own broader access, exposing information the employee was never meant to see. Nothing has been misconfigured and no policy has been violated. The architecture simply hasn't been designed for this.
According to the Cisco State of AI Security Report only 34% of enterprises have AI-specific security controls in place, and fewer than 40% conduct regular security testing on their agent workflows. Only 14.4% of AI agents are deployed with full security approval. In January 2026 NIST published a formal request for public comment on how to secure AI agent systems with a deadline of March 2026. The regulator responsible for setting security standards is, at the time of writing, still asking the industry how to do this.
The impasse isn't just a technical inconvenience, it's a barrier to trust at precisely the moment when faith in AI is at its lowest ebb and sinking. A YouGov survey in December 2025 found that only 5% of Americans say they trust AI "a lot" and over 40% express active distrust. Barely one in five would trust an AI system to make a decision or take an action on their behalf. More telling still, trust isn't growing. More respondents said their confidence in AI had decreased over the past year rather than increased. People are being expected to hand their most sensitive data to systems they don't understand governed by security mechanisms they can't evaluate in a context where every other week brings a headline about another breach. The black box isn't winning hearts.
One way to see the mismatch is to ask a few simple questions that most non-technical people can answer without thinking: would you give a new contractor your email password? Would you let them log into your bank account? Would you grant them unfettered access to your private correspondence? In most cases the answer is an emphatic "No!", even if the contractor is intelligent, diligent, and has a good record. That refusal isn't primarily a judgement about competence, it's an instinctive reaction to boundaries. It's about trust.
Human institutions have spent centuries refining the most battle-tested access-control architecture in existence: the managed working relationship. Onboarding procedures, probationary periods, tiered clearances, delegated authorities, supervisory oversight, performance review, termination protocols. Every organisation already runs this system and every adult already understands it. Enter "the Contractor".
The contractor model doesn't ask the security industry to invent new agentic permissions frameworks. It points out that we already have one, purpose-built for the closest thing to AI that has ever existed: other people. The principle is straightforward. Instead of embedding the agent behind the user's security moat and giving it the user's own credentials, it treats the agent as a separate entity in the system, as a contractor rather than an app. It gets its own phone number, email address, messaging accounts, and project workspace. The user assigns specific, bounded, time-limited permissions to the agent's accounts exactly as they would to a new hire or external consultant.
At this point, it's worth clarifying a key distinction that the technology industry has quietly elided. When the industry talks about "delegation" it means identity delegation, giving the agent your login, your session token, your API keys. A delegated agent operates as you, with access to everything you have. This isn't what the word means anywhere else in human usage. When a manager delegates, they assign tasks and set outcomes. They forward the email that needs summarising. They share the document that needs reviewing. They add the contractor to the project channel. The information flows to the worker one item at a time and the worker operates as themselves. This is task assignment, and it's the opposite of identity delegation in one critical respect. Identity delegation is permissive by default, granting access to everything and hoping generic guard-rails will contain the risk. By contrast, task assignment is restrictive by default, granting initial access to nothing and sharing only what the task explicitly requires.
Consider a simple example. You want your agent to book a flight. Under identity delegation it logs into your email, searches your inbox for loyalty numbers, accesses your calendar to find available dates, opens your banking app, and books the ticket, all as you, indistinguishable from you in every system it touches. Under task assignment you WhatsApp the contractor: "Find me a return flight to Edinburgh, 14th to 16th March, under £200." The contractor researches options using its own browser session and sends you three choices. You tap a payment link to book the one you want. The contractor never sees your inbox, your calendar, your bank balance, or your loyalty numbers. It only sees what you choose to send it. The difference in convenience is a few seconds of friction. The difference in exposure is your entire digital footprint.
This is why the contractor model is more than just a clever architectural tweak. One of the more corrosive aspects of agentic AI adoption is that ordinary users are being asked to evaluate technical security claims they have no framework or context for understanding. Sandboxing, prompt injection defences, ephemeral containers, zero-trust architectures and their ilk are concepts that mean nothing to the average person whose main concern is whether or not it's safe to let the agent read their email, access their business data, or use their bank account. The result is a trust vacuum, where people either blindly accept risks they cannot assess or refuse to engage at all. Neither outcome serves anyone well. The contractor model reframes those heuristics. Instead of asking whether an inscrutable black box is secure enough to let an agent wield your identity, it asks whether the task itself justifies the access being proposed. The model doesn't rely on the agent being perfect, it relies on humans making the same judgment calls they're already making with their human colleagues.
The contractor framing is not without precedent. The International Association of Privacy Professionals, the global body representing privacy and data protection practitioners, independently arrived at the same conclusion in its November 2025 guidance on AI agent security: "Think of an AI agent like a contractor." The core idea is straightforward. Treat the agent as a distinct operational identity. Give it its own accounts, its own credentials, and its own bounded permissions. Assign tasks rather than delegate identity. Make its actions visible, attributable, and auditable. It's a practical governance model that mirrors how we already handle co-workers and external collaborators. The agent isn't your digital doppelganger, it's a fellow team member with a distinctive role that's explicit by default.
This repositioning doesn't eliminate all of the risks of identity delegation but it does significantly reduce its blast radius. A compromised agent with a narrow access scope can do far less damage than one suborning your identity. If something goes wrong you revoke the contractor, not your entire digital life, and the logs show what the agent did rather than rewriting history in your name. And that distinction matters as much for compliance and accountability as it does for security.
The audit trail point deserves emphasis. In any shared project workspace, whether Slack, Notion, Asana, or Teams, team members have historically relied on the assumption that actions are attributable, that when a colleague posts an update, reviews a document, or signs off a deliverable it was actually that person who did so. Under identity delegation there is no way to distinguish the human from their AI agent. Did the project lead actually review that specification or did their agent skim it and post "looks good"? Did the team member write that code status update or did their AI generate it from a glance at the commit log? Nobody in the project can tell, and the erosion of trust this creates within teams may prove as damaging long-term as any external security breach. Under the contractor model the agent posts as itself, from its own account, and every member of the team can see at a glance which contributions are human and which are not.
The liability question deserves closer examination than it typically receives. AI agents are not legal persons in any jurisdiction. They cannot be sued, cannot enter contracts in their own right, and cannot absorb liability. Their actions are legally attributable to humans or companies through existing doctrines of tort law, product liability, and negligence.
When a human contractor screws up, liability is distributed. The individual bears personal liability, the supervisor bears liability proportional to their negligence in oversight, and the organisation bears vicarious liability. But an AI agent isn't a legal person. It cannot absorb any portion of liability. All liability flows upwards to the human principal. Under identity delegation, where the principal has handed over their credentials and full system access, the legal test is whether "reasonable precautions" were taken, and granting an AI unrestricted access is extremely difficult to defend as reasonable when the security community has been loudly warning against precisely this practice.
The US AI LEAD Act proposes classifying AI systems explicitly as products. The EU's updated Product Liability Directive already extends the definition of "product" to include intangible AI software, and its proposed Liability Rules for Artificial Intelligence would shift the burden of proof on to deployers of high-risk AI systems by requiring them to demonstrate that adequate precautions were taken. Developers risk product liability claims from design defects to failure to warn. Deployers risk negligence and duty-of-care claims. As legal scholars at the University of Chicago have argued, people should not be able to obtain a reduced duty of care by substituting an AI agent for a human one.
Under the contractor model, scoped access, bounded permissions, a clear audit trail, and documented supervisory oversight are precisely the markers that courts look for. The law here is evolving rapidly and varies by jurisdiction but the direction of travel is consistent. Deployers will increasingly be expected to demonstrate that they took reasonable and structured precautions. The difference between "I gave it everything" and "I gave it only what it needed and here's the audit trail to prove it" may be the difference between a defensible position and a turkey shoot.
The contractor framing is useful because it forces honesty about trade-offs. The model doesn't ban identity delegation, it makes the escalation explicit. It's undeniably more convenient for an agent to roam freely through your inbox than for you to have to forward specific messages. It's faster for it to move money directly than to submit a payment link for action. But convenience isn't the same thing as safety. For low-risk, high-volume tasks, direct delegation might be reasonable. For high-risk domains, the friction is the point.
The contractor model scales naturally. Human working relationships do not remain static and a team member who has reliably handled individual tasks for six months may be given standing responsibility for a bigger domain. The crucial point is that humans already do this without handing over their identity. Fred may own the UI and have standing access to the design files and the front-end repository but he logs in as Fred. The CEO's PA may have authority to approve expenditure up to a defined limit but they don't log in as the CEO to do it. Broader responsibility still operates within bounded, auditable, revocable permissions attached to the contractor's own identity. The progression from cautious task assignment to confident responsibility delegation mirrors how trust develops in any professional relationship. The scope of authority grows but the identity stays separate.
The technology industry routinely cautions against anthropomorphising AI but framing the agent as a human-analogous contractor as opposed to an opaque black box gives non-technical users intuitive context and a ready-made heuristic they can apply immediately. People already know how to onboard a contractor, supervise their work, extend their access as confidence grows, and fire them when it doesn't. These are life skills, not technical esoterica, and they are the most widely-deployed trust framework in human history. "Would you give a new contractor your banking password?" is a question anyone can answer. "Would you let them send emails as you on their first day? Or indeed ever?" likewise. This aspect of the trust model doesn't need to be engineered into the product because it's already engineered into the users.
The financial dimension illustrates this neatly. At the task assignment level, the agent researches flight options and sends you a payment link; you click "book." No financial delegation is required. At the responsibility level, corporate card platforms like Brex and Revolut Business already support the issuance of virtual cards with granular, role-based controls: per-card spending limits, merchant category restrictions, per-transaction caps, automatic expiry dates, and real-time monitoring. None of this infrastructure was built for agentic AI. All of it was built for human contractors.
There is a practical objection to all of this. It sounds plausible in theory but can it work in the mess of real platforms and real terms of service? The answer is mixed. Enterprise tools already have guest accounts, scoped access, time-limited permissions and audit trails because they were built for human workers. Slack offers single- and multi-channel guest accounts with granular access and automatic deactivation when the engagement ends. Google Workspace supports domain-level delegation and scoped sharing. Microsoft 365 has guest access with conditional policies. Those features can host AI contractors without reinvention.
Consumer platforms are another story. Many are hostile to secondary identities, automated accounts, and anything that looks like a bot. The contractor model doesn't wave that away, it turns it into a policy choice for platform providers. Do they want a safe, legible path for agents, or do they want the same brittle identity-delegation practices that have already proved so risky?
WhatsApp, the world's most popular messaging service, doesn't support account delegation in any traditional sense but it doesn't need to. The agent gets a separate account with its own phone number and appears in the team's contact list exactly as a human contractor would. Here is the quiet inversion at the heart of the model. For the majority of common workflows the integration problems that challenge technology-first approaches simply don't exist. The AI contractor drops fully formed into the same digital footprint that human contractors already occupy, enabling workflow integration and security auditing in a single move. Today, no new delegation APIs are required and no platform cooperation is needed. In time, platforms that choose to build first-class support for agent identities will make this easier still but the model doesn't depend on them doing so. And as platforms continue to evolve their collaboration features, the AI contractor benefits from every improvement automatically without a single line of code being written on its behalf.
This brings us to the idea of agent identities as a platform primitive. If the industry is serious about trust it needs to make narrow, auditable delegation easy. That means short-lived, task-scoped capabilities rather than long-lived identity tokens. It means action-level confirmation for irreversible acts. It means clear audit trails and easy revocation. The contractor model is the governance layer that houses this. It doesn't replace technical controls, it gives them a saner baseline to anchor to.
Then there's the question of deployment. A separate operational identity needs a host. For individuals and people on the go the smallest realistic container isn't a desktop or a server. It's the phone. Modern flagship phones offer unified memory architectures that make them surprisingly capable AI inference devices. They are designed to run continuously with minimal power consumption. They are always connected. They are always with you. And critically, they already contain the infrastructure for a virtual person: SIM-card slots, always-on connectivity by design, messaging apps, email accounts, biometric authentication, and native support for user profiles that provide hardware-level sandboxing between the user's personal environment and the agent's operational space. A flagship phone with 16GB of unified memory costs a fraction of the price of an AI-capable desktop, draws a fraction of the power, and is designed for always-on network access without presenting the attack surface of a desktop. Users can dedicate a second handset to the role or sandbox the contractor on the phone they already carry. It's a viable deployment paradigm as well as a pragmatic governance model.
Does all of this mean the current industry approach is fundamentally flawed? Yes and no. Yes, because the assumption that an agent should operate as the user is a structural error that will keep producing incidents even as the software improves. No, because the industry can evolve. If platforms support distinct agent identities, if access can be scoped at the task level, if delegation is explicit and reversible, then most of the convenience can be retained and much of the risk neutered.
In that sense, the contractor model isn't a revolution so much as a reset of the default. It tells us where the burden of proof should sit. It insists that trust should be earned and scoped, not assumed and then patched. It gives ordinary users a way to think about safety without needing to become security engineers. That alone is an unusual and valuable contribution in a field where too many solutions are invisible to the people they are meant to protect.
It's also a reminder that the problem of agency did not begin with AI. Organisations have long wrestled with how to balance efficiency with oversight and delegate authority without losing control. The AI industry did not invent those questions, it inherited them. The category error has been the assumption that a structural problem can be glossed over with the occasional security patch.
A mature answer will be hybrid. It will combine the contractor model as a governance framework with capability-based access as a technical mechanism to keep the inevitable failures from turning into catastrophes. It will also require platforms to choose whether they want agents to be legitimate participants in their ecosystems or shadow users riding on co-opted credentials.
Consider the contrast. Before a single self-driving vehicle was permitted on the public highway, the technology underwent years of regulatory scrutiny, billions of dollars in safety R&D, and tens of thousands of hours of closely-supervised test-driving on closed courses. Compare that with the way AI agents are being rushed to market, with access to banking credentials, medical records, and confidential business data on the strength of – what, exactly? A terms-of-service checkbox? A boilerplate disclaimer? The recklessness of the industry's approach thus far is hard to overstate.
The comforting assumption, particularly among non-technical users, that the cybersecurity industry is quietly taking care of all this in the background is equally reckless. It isn't. The security industry's current approach to agentic AI has been to apply the same tools it uses for human users: access control lists, permission management, endpoint monitoring. But these tools assume a human actor, operating at human speed, within a single session. AI agents break every one of those assumptions. The defenders aren't just struggling to keep up, they're on the wrong racetrack entirely. The contractor model doesn't compete with technical security controls. It provides the governance framework those controls have been missing, a coherent answer to the question of what an agent should be allowed to do, grounded in centuries of human best practice.
Right now, we need effective, low-friction, high-trust ways of introducing artificial intelligence into our existing social, commercial, and institutional fabric, an integration philosophy flexible enough to encourage evolution but curated enough to prevent runaway harm; a framework that simultaneously enables and regulates. The contractor model offers a way of bringing highly risky but undeniably useful agentic AI into the human mainstream by aligning it with the networks of trust we already maintain.
Identity delegation grabs the keys to the castle by default. The contractor is asking for permission to join the team. If you wouldn't entrust something to a team member maybe you should think twice about giving it to an AI. That isn't a sentimental argument, it's a practical rule of thumb that reintroduces judgment into a space that has been too eager to trade it for convenience. The future of agentic AI will not be decided by clever sandboxes alone, but by our ability to make them bounded, accountable, and above all, legible. The contractor paradigm is a good place to start.
■