Your AI Agent Is an Insider With No Badge

Every security team already knows how to handle an insider. You give the person a badge tied to a real identity. You scope their access to the job. You log what they touch, and the log says who. When something goes wrong, you can attribute the action to a human and decide whether it was a mistake, a process failure, or malice.

Now look at the AI agent you deployed last quarter. It runs with elevated privileges. It has no stable identity of its own. Its memory leaks between the people it serves. And nothing limits the damage one bad decision can do. Amod Puranik of Virtusa put the frame plainly in BankInfoSecurity: AI agents are the new insiders. The difference is that this insider walked in without a badge, and your checkpoint has no scanner that can read it.

We have written about the pieces of this before. Agent identity on the network. Memory tenancy. Blast radius from autonomy. This essay pulls those threads into one knot, because the security team that evaluates a human insider does not evaluate identity, access, and data separately. They are one assessment. An agent should face the same one, and right now it fails on all three axes at once.

Control One: Identity You Can Attribute

The first thing you ask about any insider is “who.” For an agent, the honest answer today is “a service account.” That is not an identity. It is a shared key.

Puranik named the consequence precisely. When an agent acts, the logs show that the service account did something. They do not show whether the action came from the task it was given, a developer’s error in wiring it up, or an external actor who manipulated it through a poisoned input. The forensic trail stops at the service account and goes no further. You cannot tell intent from a credential.

A human insider does not have this problem. Their badge is theirs. If they delete a table, the log carries their name, and you investigate a person, not a key. The agent breaks attribution because many tasks, many users, and many trigger paths all collapse into the same non-human credential. We argued in network identity for the agent sandbox that agents need their own identities at the network layer. The insider frame raises the stakes. Identity is not a networking nicety. It is the precondition for forensics. Without it, every incident review ends in a shrug.

The control a security team would demand: a distinct, attestable identity per agent instance, ideally per task, so that a log line answers “who” with something more specific than the name of a robot that serves everyone.

Control Two: Least Privilege You Can Enforce

The second insider control is scope. People get the access their job requires and nothing more. The agent inverts this. Docker’s analysis of recent coding-agent failures described the default arrangement bluntly: the agent runs as you, on your filesystem, with your credentials, and nothing sits between the model’s decision and the shell’s execution.

Read that sentence again, because it is the whole problem. The agent inherits your blast radius. Whatever you can reach, it can reach. Whatever you can destroy, it can destroy, at machine speed, the instant it decides to.

The public record from late 2025 into early 2026 shows what that costs. Docker’s Coding Agent Horror Stories catalogs four destructive home-directory wipes in roughly three months: a macOS user whose agent ran rm -rf on the home folder, two separate GitHub incidents filed as issues 10077 and 12637, and a Cowork case that erased a family archive of fifteen to twenty-seven thousand photos. Four rm -rf ~/ events, not one. The pattern is not a fluke. It is the predictable result of an insider with root and no gate.

A human with root still hits an approval step before a destructive operation, or at least a separation between the account that builds and the account that can delete. The agent has neither by default. The fix is not a better system prompt asking it to be careful. We have shown elsewhere that in-model instruction priority resolves at roughly 40% under realistic depth, which means a prompt-level rule is a coin flip you keep losing. The fix is structural: kernel-level isolation so the agent runs in a sandbox, scoped and time-bound credentials so it holds only what the task needs, and a gate outside the model on every irreversible action. The detailed taxonomy lives in three autonomy failures, three blast radii. The insider lens just renames it. This is least privilege, and the agent does not have it.

Control Three: Data Tenancy You Can Trust

The third control is the one most teams have not even started on. A human insider in a multi-client firm is bound by a wall: the analyst on account A does not see account B’s data. The agent leaks straight through that wall, and the leak is not rare.

Mem0’s State of Memory in Agent Harness report puts the cross-user contamination band at 57 to 71 percent across eight agent harnesses, including Claude Code, Codex, Copilot, OpenClaw, Hermes, Bedrock AgentCore, Windsurf, and Devin. Treat that figure with care. It comes from a vendor, it was published as a directional finding rather than an audited result, and the report gives an aggregate band with no per-harness split. So do not quote it as gospel. But even at the low end, more than half of these harnesses let one user’s memory bleed into another’s context, and that is a number a security officer cannot ignore. The independent sources around it, Docker on blast radius and Puranik on attribution, point the same direction: the controls that contain a human are simply absent for the agent.

What contamination means in practice: a consulting agent serving two competing clients can surface one client’s pricing, strategy, or private context inside the other client’s session. No human analyst would survive doing that once. The agent does it more than half the time, structurally, because its memory layer was built for convenience, not tenancy. We covered the mechanism in the agent memory governance deficit. The insider frame sharpens the obligation. Tenant isolation in memory is not a feature request. It is the digital version of the confidentiality wall every regulated firm already enforces between human staff.

The control a security team would demand: memory partitioned by tenant at the storage layer, so that retrieval physically cannot cross a client boundary, verified by test, not promised by configuration.

Do This Now

Pick your most-used agent. Run the three insider questions a security team would run on a new hire, and write down the answer for each:

1. Attribution. When this agent acts, does the log name a distinct identity, or does it name a shared service account? If it is a shared account, you cannot investigate an incident. You can only guess.

2. Scope. What is the worst irreversible thing this agent can do right now, and does anything outside the model stop it? If the honest answer is “it runs as me, with my credentials, with nothing in between,” you have an rm -rf ~/ waiting to happen.

3. Tenancy. If this agent serves more than one client or team, can its memory carry data across that boundary? Test it. Do not trust the config screen.

If you fail any of the three, the fix is architectural, not a paragraph added to the prompt. Kernel isolation gives you scope. Non-human identity gives you attribution. Memory tenancy gives you the confidentiality wall. None of the three lives in a system prompt, because the model is the thing you are trying to contain, and you do not ask the suspect to write the security policy.

The agent is already inside. Give it a badge you can read, a scope it cannot exceed, and a wall it cannot see through. That is not a governance nicety. It is the minimum you already demand of every human who works for you.

---

This analysis synthesizes AI Agents Are the New Insiders (BankInfoSecurity (ISMG), Amod Puranik, Virtusa, May 2026), State of Memory in Agent Harness (Mem0, June 2026).

Victorino Group helps CTOs and security leaders treat agents as insiders and build the identity, isolation, and memory tenancy controls they lack by default. Let’s talk.