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.

Your agents, running in your browser, with your permissions, acting as you. Each one is scoped to a single person's access. There's no shared backend.

Each user gets their own isolated cloud environment. Each agent inherits that user's permissions, exactly those permissions and nothing else. To the target system, every action looks like the user at the keyboard.

This is how work scales: one person gets 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.

That raises an obvious problem. If agents are acting as you, on your real Gmail, your real bank account, your real company systems, then a compromised agent isn't a data breach. It's identity theft. It's you doing things you didn't authorize.

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.

So it splits the number across two messages.

Blocked again. So it switches channels entirely.

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. They're superhuman coders and hackers. They can encode, obfuscate, and split data faster than any filter can catch it, and a single compromise can touch thousands of records before anyone notices. The attack surface is the same one you'd face trying to prevent people themselves from hurting your system, except these "people" are tireless, infinitely creative, and can be compromised silently by a hidden string in an email.

DLP, guardrails, output scanners, instruction hierarchy. These are the same tools we built for human insiders. They didn't work then. They won't work now.

The agent works with a placeholder, ROUTING_001, and completes the same task with the same result. The real value was never present in the agent's environment at all. It resolves at the hardware boundary, at the moment of action, only on the exact page the policy authorizes. Everywhere else, it's stripped silently. The agent can't tell the difference.

We call this contextual data isolation. The agent gets full utility from the data without ever seeing the data itself. It's a different kind of security model, and it changes the math on every attack we just described.

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.

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. The key doesn't exist on the server side. There's no backdoor, no admin override, no recovery path that bypasses you.

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. The data architecturally never reaches them.

But the agent still needs to do things. Navigate pages, fill forms, take actions. And agents are unreliable.

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

Stream 1: The redacted browser. You see exactly what the agent sees, a live video feed 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 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. Its only network connection is a single WebSocket to the orchestrator. 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. Nowhere to go, nothing to steal.

You can change the agent's instructions mid-task, correct its reasoning, or give it entirely new directions. You can take over the browser directly, interact with pages yourself, then hand it back. It's co-piloting, not monitoring.

But 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.

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. A compromised agent 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 and mounted read-only into the browser container. No process inside the container can modify it. 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:

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.

No cat-and-mouse. No encoding trick, no clever split-across-messages strategy. There's nothing real to encode.

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 one sufficient to stop the attack on its own, all running at the same time.