Security Model

What Levee assumes about the AI agent, the controls it places around it, where your data goes, and the limits reviewers should understand

Levee assumes the AI agent could be tricked into misbehaving, so it puts every control outside the sandbox, where nothing the agent reads or does can change it. The agent works freely on its project folder; everything else goes through Levee, follows your policy, and is recorded.

This page explains the reasoning, the controls in five layers, where your data goes, and the limits of the design. It is the page to share with a security, risk, or compliance reviewer.

Why assume the agent is compromised?

AI agents follow instructions found in what they read: documents, spreadsheets, web pages, emails. A hidden instruction in any of these (a prompt injection) can turn a well-behaved agent into one that tries to read secrets, reach internal systems, or send data out. Controls inside the model, or in the agent's own permission prompts, can be talked past by exactly that attack.

So Levee treats the agent inside the sandbox as fully compromised and places every control outside it:

• The agent runs in a sandbox that contains only its project and the files the user chose to share.
• Everything the agent reaches beyond that goes through a Levee channel that applies your policy.
• Windows blocks any attempt to go around those channels.
• Every decision is recorded in an audit trail on the computer.

Layer 1: what is inside the sandbox?

Only the project and what the user shares. Each project runs in its own Windows container on the computer, using process isolation (no Hyper-V needed).

• The project folder is the only host folder the sandbox reads and writes directly. It appears at C:\workspace. The rest of the user's profile, documents, credentials, other projects, and network shares are not present.
• Files and folders the user shares with the project, from the app's Access Policy tab, appear under L:\, read-only or read and write. Access to them goes through Levee's file channel, not a direct link to the folder. Anything not shared does not exist for the agent. See File access.
• Project folders must be local folders inside the user's own profile. Levee refuses network paths, system folders, and other users' folders.
• AI tools are mounted read-only.
• Each project has its own sandbox, its own signed-in web sessions, and its own approvals. A remembered approval belongs to one project and to the user who made it. Nothing is shared between projects.
• Only one project runs on a computer at a time.

Layer 2: can the sandbox reach the network directly?

No. The sandbox has no direct network access. Windows blocks any traffic from the sandbox that does not go to a Levee channel, including traffic from programs that ignore proxy settings.

• The block is in place before the agent can run. If Levee can't set it up, the project does not start. There is no "start without protection" option.
• When a project stops, the block is removed only after Levee confirms the sandbox is gone. If it can't confirm that, the block stays.

Layer 3: how is each kind of access controlled?

Each way the agent can reach the outside world has its own Levee channel, which understands that kind of traffic and applies policy to it.

Layer 4: credentials never enter the sandbox

No Levee channel places a real password, key, or session inside the sandbox.

• Model keys stay on the host. The agent receives a placeholder key that only works through Levee and is useless if copied out.
• Database credentials and connection strings stay on the host. The agent sees an alias such as DSN=levee-sales.
• Web sign-ins stay on the host. Levee attaches the session to the agent's requests; the agent never sees the cookies.
• Search provider keys and package registry credentials stay on the host.

A compromised agent has nothing to steal that works outside the sandbox.

Layer 5: people in the loop

For destinations your policy marks for review, Levee pauses the request and asks the person running the project, showing the exact resource and access level. Unanswered requests are denied after five minutes. See Approvals.

Rules every channel follows

Where does your data go?

All enforcement happens on the computer. Data leaves it only to the providers your organization chooses.

• Enforcement happens on the computer. The sandbox, the channels, policy decisions, and the audit trail all run locally. Agent traffic is not routed through Vediram servers.
• Model calls go directly from the computer to the provider your organization configures (Anthropic, OpenAI, Azure OpenAI, Azure AI Foundry, AWS Bedrock), or to the Vediram LLM Gateway if your organization chooses to use it.
• Web searches go to the search provider your organization chooses (Brave, Linkup, or Tavily).
• Vediram Cloud receives only what you turn on: policy is downloaded from it, and audit events are forwarded to it only if you turn on forwarding (off by default). Model prompts and responses are never forwarded.

Limits you should know

These follow from how Levee works. Knowing them helps you write policy and describe the control accurately.

Process isolation is not a Microsoft-serviced security boundary. Levee sandboxes are Windows containers using process isolation, which share the computer's Windows kernel. Microsoft does not treat process isolation as a security boundary for servicing purposes, and positions process-isolated containers on client Windows for development and test scenarios. Levee's perimeter is its network block, its control of every channel, and its custody of credentials, not the container-to-kernel boundary. Keep computers patched, and include this point in your risk assessment.

Host and sandbox Windows versions must match. Process isolation needs the sandbox image to be built for the same Windows version as the computer. After a Windows feature update, or occasionally a monthly update, the sandbox may need a matching image before projects start again. See After a Windows update.

Anything you allow can be used to send data out. An allowed website, an approved search, a permitted database, or a shared folder with write access is also a possible way out for a compromised agent. Allow narrowly: specific hosts rather than wildcards, specific methods where possible, escalate rather than allow for gray areas, and read-only sharing unless the agent must write.

Web inspection is per domain and has trade-offs. Without inspection, Levee sees and controls the destination host of an HTTPS connection, but not the path, method, or content inside it. With inspection turned on for a domain, Levee decrypts that traffic inside the sandbox's trust boundary and can apply method rules and record requests in detail, but programs that pin a specific server certificate will refuse the connection.

Private network destinations are not reachable over the web channel. Host names that resolve to private, loopback, link-local, or reserved addresses are always refused, even with an allow rule, so an allowed name can't be pointed at internal systems. Internal databases and Office content are reached through their own governed channels instead.

Prompt filters are a hint, not a boundary. Model prompt filters match terms after normalization, but paraphrasing, encoding, or other languages get past them. Use them to catch accidents, and rely on model allow-lists, budgets, and network policy for control.

SQL checks are a guard, not a full SQL parser. Levee classifies each query's verb and tables and blocks known dangerous patterns, but a determined attacker can write SQL that gets past text inspection. The database's own permissions for the data source are the real ceiling: give each data source you expose through Levee an account with no more privilege than you intend the agent to have. Levee narrows those permissions and never widens them.

Approvals are only as good as the person answering. Use deny rules, which a user can't approve, for destinations that must never be reached.

Levee protects against the agent, not against a local administrator. A user with administrator rights on the computer can change local policy, stop Levee, or delete the local audit files. Manage policy centrally, restrict local administrator rights as you would for any security control, and forward the audit trail off the computer as it is written.

Everything inside the project folder is the agent's to change. The agent can read and change every file in its project, and every shared item it has write access to. If Git is installed, Levee saves a checkpoint of the project folder when the project stops so you can review and undo changes. Review the agent's work before it leaves the computer, as you would a colleague's.

Related

• FAQ
• How policy works
• Audit event reference