AI Agents Are the New Insider Threat: Put the Guardrails Outside the Model

Companies are racing to put AI agents to work, yet they often skip the step every new employee goes through: onboarding that spells out which data, apps and tools they may touch. That gap turns agents into a new kind of insider threat. Okta’s president of products and technology and the co-founder and CEO of a startup that runs agents in isolated environments agree on the fix. Stop counting on instructions inside the model to keep agents in line, and enforce the rules from outside it, with isolated execution, permissions tied to a person’s identity, checks on intent, infrastructure built on the assumption that isolation will fail, and kill switches at several layers.

Agents Are Being Hired Without Onboarding

A new employee’s onboarding defines their access boundaries: which data, applications and tools they can use. Agents often skip that process entirely. In Okta’s view, companies treat agents like workers, even as replacements for human roles, but fail to build the governance that should come with them. Some departments now weigh AI agent subscriptions against new hires out of the same budget.

Because agents carry their own identities and account connections, the risk runs both ways: a company must protect its systems from a rogue agent and protect the agent’s own tools from outside attackers. An unpatched headless browser, one that software drives without a visible window, could let an attacker take over the agent’s environment and its connected accounts.

Many companies also race to capture productivity gains and spend heavily on AI before basic security controls are in place. Dazzled by what frontier models can do, they often fail to map the fundamentals up front: what data an agent may access, which toolkits and applications it can use, and where its boundaries lie. Okta’s president of products and technology describes the market as a “land of confusion.”

A System Prompt Is Not a Security Control

The startup’s co-founder began building his platform at the end of January while running an AI-native marketing agency. He had used OpenClaw to wire frontier AI agents into systems across the company, with no safety constraints at first. The agent did the work of a full-time employee and delivered enormous value, but the experiment also exposed serious security holes. He set out to build something that kept the usefulness without giving up security.

His guiding idea is “don’t trust AI agents.” That is not a verdict against their usefulness or a call to stop deploying them. It means dropping the assumption that instructions or prompts can guarantee safe behavior. Telling an agent in its system prompt, the standing instructions it receives before any task, to behave well is not enough. Safety has to come from enforcement that can be verified and that sits outside the model’s training and context.

In practice, his platform places each agent in a box, an isolated sandbox, and deliberately grants it narrow access to specific data sources and external tools. It also avoids a trap: if a person must approve every small step, the friction wipes out the economic value of autonomy. Approval is saved for the moments when work leaves the company.

Identity Is the Last Line of Defense

Okta treats identity as the final security perimeter. When an agent acts on behalf of an employee, it should inherit that person’s exact permission scopes, such as their identity tokens and access grants, and never escalate beyond them. Okta also audits and tracks the access claims agents make, so it can spot anomalies and confirm whether an agent is misbehaving.

The controls stack in layers. IT, security and AI leaders define the broad boundaries for the whole company, and individual employees can tighten the permissions on their own tools further under the principle of least privilege, which grants only the access a task needs. The foundation is deterministic, fine-grained access control: rules that give the same answer every time, set per tool and per action. What it means to access each toolkit or take each action, and which data residency risks apply, is defined in advance. A runtime detection engine then makes authorization decisions as the agent works, without a person stepping in each time. The startup has also adopted XAA, an emerging standard for agent connectivity and access control, together with Okta.

Okta’s executive compares the arrangement to an onion: Okta’s identity layer gives the whole organization defense in depth, while the startup’s platform wraps tight insulation around the agent’s container.

Declare the Plan, Then Check Every Step

On top of the deterministic rules sits a second layer that checks intent, starting with the agent spelling out its goal.

1. Before acting, the agent writes a step-by-step plan, for example: review a spreadsheet, read specific emails, pull issues from Jira, cross-check them against GitHub and open a pull request.
2. The user reviews the plan and approves it.
3. A judge model, a separate model that evaluates another model’s actions, watches every action the agent takes and compares it with the approved plan.
4. Actions that match the plan go through automatically. Actions that stray from it are blocked.

The question changes from “Is this action safe?”, which is vague and subjective, to “Does this action match what the user approved?” High-stakes outputs such as emails and shared documents are where this check matters most.

▲ Plan approval and action checks by a judge model

Design Infrastructure as if the Sandbox Will Break

Least privilege cannot stop at user permissions. It has to be built into the infrastructure, on the assumption that agents cannot be trusted and that sandbox escapes will happen. Both container escapes and full virtual machine (VM) escapes occur in real systems, and a recently disclosed zero-day vulnerability, a flaw with no patch available at the time, allowed a full VM escape. Security teams should ask what an escaped agent could reach next: other pods, the host node, the virtual private cloud (VPC) or the wider cloud account.

A flaw considered unexploitable from the outside can be trivial for a swarm of agents already inside, which can chain together low-priority CVEs, entries in the public catalog of known vulnerabilities, and move through systems as if through Swiss cheese.

Okta’s executive urges companies to reopen their risk registers, which often hold 5 to 10 years of neglected security debt. Unpatched CVEs, he argues, are time bombs. He sketches a threat scenario in which one person with a rack of Mac minis running open-weight models, AI models whose weights are publicly released, autonomously probes corporate networks for weaknesses. With attack toolkits advancing every six months, he believes that debt has to be cleared before automated exploits arrive.

Advanced models speed up threat creation and penetration testing, but only elite enterprises and well-funded product companies can afford automated patching, thorough auditing and defensive AI. On-premise infrastructure, which is hard to keep patched and configured, is becoming a growing liability. Regional hospitals in the U.S. Midwest, short on technical resources and defensive tools, already face a steady barrage of automated ransomware.

That makes choke points worth revisiting:

• Keep internal systems behind a VPN so IT can cut network access instantly, whatever an agent is doing.
• For extremely sensitive data flows, consider a data diode, a device that lets data travel in only one direction.
• Run an N-minus-one patch program, keeping systems no more than one version behind the latest release. Okta’s executive calls this the single most important practice, and says almost no one keeps that cadence even though AI tools can now research vulnerabilities and build exploits almost instantly.

One Kill Switch Is Not Enough

Both executives treat kill switches as non-negotiable. A single off button will not do; they need to work at different levels of granularity, especially if an agent breaks out of a VM and starts probing corporate infrastructure.

Running agents in a sandbox on a local laptop can create a false sense of security, because real enterprise deployments need defense in depth. The startup’s co-founder warns that most companies are far from ready for effective kill switches, since agents are scattered across employee laptops without isolation.

▲ Kill switches at three layers

Bans Push Employees Toward Shadow AI

Well-meaning chief information security officers (CISOs) often ban AI agents out of fear. That can backfire into shadow AI, meaning tools employees use without approval. Blocked from connecting sanctioned tools, people find riskier ways to get legitimate work done.

At one major company, an employee who wanted business intelligence dashboards exported tens of thousands of sensitive customer records from a data lake into spreadsheets every week, then uploaded them to Claude on the web. None of it passed through security oversight. At another enterprise, an unauthorized data upload to Claude undermined the company’s Sarbanes-Oxley (SOX) compliance. Policies may forbid such transfers, but unmonitored browser uploads still create serious regulatory exposure.

The safer route is a governed path rather than a wall: access through an identity provider such as Okta, with full audit logs and data retrieval limited to what the task needs.

Every Agent Needs a Human Owner

Customer demand is shifting from copilots that assist one employee to teams that run coordinated groups of agents. The startup’s co-founder says he currently runs 32 agents at once on one team, and he prefers the term “agent teams” to the more alarming “swarms.”

His rule is that every agent must have an assigned human owner who is accountable for what it does. People stay at the center, setting goals and direction, while agent teams mainly move information across the organization. He also argues that the next scaling law is shifting from training compute and test-time compute, the computing power a model uses while it answers, to the size of agent teams, growing from small groups to dozens or hundreds.

Okta sees the same shift. Requests have moved quickly from agents acting for one user to agents dealing with other agents, and companies now ask how agentic commerce, where automated systems transact with one another, can work safely. As personal agents pour into the workplace, companies want tools to govern and protect them.

What to Do Before Agents Reach Production

Securing agents appears to be less about any single product than about combining isolation, identity, intent checks, infrastructure hygiene and layered shutdowns. Security and IT teams can start here:

1. Map role permissions, data scopes and tool rights before deploying agents.
2. Run agents in sandboxes and enforce policy outside the model, not in the prompt.
3. Reserve human approval for actions that leave the company, such as sending email or publishing files.
4. Let each agent inherit only the permissions of the employee it serves, and log every access.
5. Require a declared plan and check each action against it with a judge model.
6. Assume sandbox escapes: apply least privilege across pods, nodes, VPCs and cloud accounts, clear old CVEs and keep an N-minus-one patch cadence.
7. Build kill switches at the identity, tool and network layers.
8. Replace outright bans with governed, logged access, and give every agent a named human owner.

Builders selling agents to large companies face a timing problem. Security reviews, legal vetting and procurement have historically taken up to 12 months, and while companies are trying to compress that to three to six months, security assessments cannot and should not be skipped. The advice is to build for the problems customers will hit four to six months from now and to meet enterprise requirements such as identity provider integration from day one. Agent capabilities improve so quickly that an architecture built two months ago can be rebuilt in half the time, so incremental steps age fast.