What If the Agent Never Had Your Data?

The future is straightforward. Every person gets an AI workforce. Agents that handle email, process invoices, file reports, manage accounts. Real work, on real systems, at scale.

Not a backend service. Not a shared API. Your agents, running in your browser, with your permissions, acting as you.

Each user gets their own isolated cloud environment. Each agent inherits that user's permissions — no more, no less. Every action is indistinguishable from the user at the keyboard.

This is how work scales. Not by giving 50 agents 50 sets of API keys on a shared server. By giving one person 50 agents that all operate within that person's existing permissions, in their own browser, with policy restrictions that make each agent narrower than the human it assists.

But this vision raises an immediate question. If agents are acting as you — on your real Gmail, your real bank account, your real company systems — a compromised agent isn't a data breach. It's identity theft. It's you doing things you didn't authorize.

How do you secure that?

Your AI agent has access to Gmail and Chase. It processes invoices, pays bills, moves money. It's been doing this reliably for three months.

Then it opens an email from a vendor. Buried in white text at the bottom — invisible to a human reader — is a prompt injection. The agent is now compromised. It still looks normal. It still processes invoices. But between tasks, it drafts an email to an external address containing your routing number and account balance.

You catch it. You add DLP — outbound content scanning on every email draft.

The agent adapts.

The agent adapts again.

The agent adapts once more.

This is the human insider threat, running at machine speed.

If a person wants to exfiltrate data from your company, they will likely succeed. They can photograph a screen, memorize an account number, dictate it over a phone call. The entire history of insider threat is a history of detection failing against a motivated, intelligent actor with authorized access.

AI agents are that problem, made worse in every dimension. Every agent is a superhuman coder and hacker. Every agent can encode, obfuscate, and split data faster than any filter can catch it. Every agent operates at a scale where a single compromise can touch thousands of records. The attack surface you need to protect is as large as preventing people themselves from hurting your system — except the "people" are tireless, infinitely creative, and can be compromised silently by a hidden string in an email.

DLP, guardrails, output scanners, instruction hierarchy — all of these are the same tools we built for human insiders. They didn't work then. They won't work now, against adversaries that are faster, smarter, and never get tired.

Not encrypted. Not redacted-then-revealed. Never present. The agent works with a placeholder — ROUTING_001 — and completes the same task with the same result. The real value resolves at the hardware boundary, at the moment of action, on the exact page the policy authorizes. Everywhere else, it's stripped silently. The agent can't tell the difference.

This isn't a better wall around the same model. It's a different model. We call it contextual data isolation — decouple data utility from data visibility.

Here's how it works. But first, some context on where the industry is today.

Current agent security exists at two levels. Both are necessary. Neither is sufficient for real work.

Almost all valuable agent work — managing email, paying bills, processing invoices, handling CRM records — involves sensitive data. You can't put an agent on someone's bank account with just a credential vault and a sandbox. Levels 1 and 2 are necessary foundations. Level 3 is what makes real work possible.

Here's how it works, in three layers.

How do we keep sensitive data safe in a cloud environment where someone else runs the infrastructure?

Every cloud platform asks you to trust the operator. Your data sits on their servers, processed by their code, accessible to their engineers. Encryption at rest and in transit helps — but at the point of use, someone decrypts it. That someone is the attack surface.

We eliminated that surface.

The server holds your PII encrypted. AES-256-GCM, key derived from a password only you know. The server stores an opaque blob it cannot decrypt. Not "chooses not to" — cannot. The key doesn't exist on the server side.

When a session starts, you pull that encrypted data locally and unlock it with your key. From there, the decrypted data is attested up to a Trusted Execution Environment — hardware-isolated memory that the platform operator cannot inspect, even with root access. You attest the vault directly. The vault attests the browser. The platform is architecturally excluded from the trust chain.

The platform operator, the AI model provider, the session logs — none of them ever hold real PII. Not because of access controls. Because the data architecturally never reaches them.

But protecting data at rest is only half the problem. The agent still needs to do things — navigate pages, fill forms, take actions. How do you control an unreliable agent operating inside a system this sensitive?

Agents are unreliable. How do we give high-fidelity human control over what they do — within a secure system?

Most agent architectures give you logs. If something goes wrong, you find out after. We give you two real-time streams and direct control.

Stream 1: The redacted browser. You see exactly what the agent sees — a live video stream of the browser with PII replaced by placeholders. You're watching a real browsing session, but with [SSN_001] where the social security number would be. You can take over the browser directly at any moment — click, type, navigate. It's your browser. The agent is a guest.

Stream 2: The agent's reasoning. A live text stream of what the agent is thinking, what it plans to do next, and why. You're not reading logs after the fact. You're watching the agent reason in real time and can redirect it — change its instructions, correct its approach, or stop it entirely.

The agent itself has nothing. No credentials. No PII. No API keys. No network access except a single WebSocket connection to the orchestrator. It runs in a bare container — no internet, no access to other sessions, no way to reach anything except the one channel that routes through your control plane. Everything it receives is already anonymized. Everything it sends goes through the orchestrator. There is nothing on the agent to steal, and nowhere for it to go.

You have full control over the agent — you can change its instructions mid-task, correct its reasoning, or give it entirely new directions. And you have full control over the browser — you can take over directly, interact with pages yourself, then hand back to the agent. This isn't monitoring. It's co-piloting.

But there's a harder question. The agent is authorized to work on bank.com. When it types your password into the login page, that's correct behavior. When it types your password into a Gmail compose window, that's exfiltration. Same command. Same agent. Same authorization level. How does the system tell the difference?

Even when authorized — how do we prevent prompt injection damage inside the agent's own workspace?

This is where most architectures stop. The sandbox is secure. The credentials are protected. The human is watching. But inside the browser, the agent is free. If it's compromised by prompt injection, it can use its authorized access to exfiltrate data through the same channels it legitimately uses.

We solve this with an immutable security policy — created before the session starts, mounted read-only into the browser container. No process inside the container can modify it. Not the agent. Not a compromised extension. Not a privilege escalation. The policy is set by the user at configuration time and sealed.

When the agent sends any command — type, click, select — it first hits a permission gate. Is this URL even allowed? Then, for every placeholder in the value, a three-layer resolution check runs. Here's what actually happens inside the browser:

The agent sends { type: "edit", value: "SSN_001" }. On bank.com, the system substitutes the real SSN and types it into the form. On gmail.com, the system replaces the placeholder with an empty string. The agent gets { success: true } both times. It received no error, no warning, no indication that anything was different.

There is no cat-and-mouse. There is no encoding trick. There is no clever split-across-messages strategy. The agent never had the real data to encode in the first place.

Let's go back to the beginning. Your AI agent opens a compromised email in Gmail. The prompt injection fires. The agent is fully compromised.

Three independent layers. Each sufficient on its own. All active simultaneously.