AI Tools

Which AI agents run in Levee, how IT makes them available on a computer, and how users turn them on for a project

The AI agent itself (Claude Code, Codex CLI or GitHub Copilot CLI) is installed separately from Levee, as a tool. IT places approved tool versions on each computer, and users turn a tool on for each project. A project keeps the tool version it started with until the user chooses to upgrade, so nothing changes silently.

Which agents are supported?

Each tool declares the websites it needs to work, for example its vendor's service. Turning a tool on asks the user to approve those sites (see Turning a tool on in a project):

The model calls of Claude Code and Codex CLI go through Model Access, where you choose the provider and approve models.

For your IT team: making tools available

Tools live in the tool catalog on each computer:

%ProgramData%\Vediram\Levee\tools\<name>\<version>\

Each version folder holds the tool's manifest, levee-tool.json, and its files. Several versions of the same tool can sit side by side; each project uses the version it turned on. The Levee installer adds no tools, and Levee never downloads one by itself.

To add a tool version:

1. Obtain the tool package from Vediram. Each package is a .tar.zst archive with a matching .sha256 checksum file.

2. Verify the checksum before using the package:

   $archive = '.\claude-code-<version>.tar.zst'
   $expected = (Get-Content "$archive.sha256" -Raw).Split(' ')[0].Trim()
   $actual = (Get-FileHash $archive -Algorithm SHA256).Hash
   if ($actual -ieq $expected) { 'Checksum OK' } else { throw 'Checksum mismatch: do not use this package' }
   

3. Extract the archive into the catalog so that levee-tool.json ends up directly inside the version folder, for example:

   C:\ProgramData\Vediram\Levee\tools\claude-code\<version>\levee-tool.json
   C:\ProgramData\Vediram\Levee\tools\claude-code\<version>\payload\...
   

   Use a tool that can read Zstandard-compressed tar archives.

4. Make the catalog read-only for standard users. Only administrators (and the Levee service, which runs as SYSTEM) should be able to write under %ProgramData%\Vediram\Levee\tools.

5. Restart the Levee service so it reads the catalog again. Do this when no project is running:

   Restart-Service LeveeService
   

The service reads the catalog when it starts. A tool folder added while the service runs is not visible until the next restart.

To roll tools out to many computers, package steps 3 to 5 in your endpoint management tool (for example as an Intune Win32 app or a Configuration Manager application) together with the verified archive.

Removing a tool version

Projects keep the exact version they turned on, so first make sure no project still uses that version. Ask users to upgrade or turn the tool off, then delete the folder and restart the service.

Turning a tool on in a project

Users turn tools on in the Levee app: open the project, go to its Settings tab, and find the Tools section. It lists every tool in the catalog with its latest version. A tool turned on or off applies from the project's next start; a running project keeps the tools it started with.

When a user turns a tool on, Levee shows the sites it needs and asks the user to Approve and enable:

• All or nothing. The tool is turned on only if all its required sites are approved.
• Policy has the final say. If your policy explicitly denies any of the tool's sites, the tool cannot be turned on, and the user sees Blocked by admin policy: <hosts>. You can use this to ban a tool: deny its vendor's site.
• Approval is not an allow rule. The user's approval is remembered for that project and answers approval prompts for those sites. For the tool to actually reach them, your web access policy must allow them or send them for approval (escalate). With a strict deny default and no rule for those sites, the tool is turned on but cannot connect.
• Turning a tool on is recorded in the audit trail as tool.enable.approved, with the approved sites.

Once on, the tool appears inside the sandbox under C:\tools\<name>, read-only, and its commands are on the PATH.

In Easy mode, the first chat message in a project that has no agent turns on the default agent (see below) and approves its required sites on the user's behalf. Your policy's veto still applies: if a required site is denied, the chat reports that the agent is blocked. This automatic step is audited like a manual one.

Versions and upgrades

• A project keeps the version it turned on. Adding a newer version to the catalog never changes a running or existing project.
• When a newer version is available, the Tools section shows an Upgrade to button with the new version number. Upgrading is always the user's choice. If the new version needs more sites, the user approves them (Approve and upgrade), and your policy can veto them as for turning a tool on.
• Turning a tool off removes it from the project and removes only the site approvals that came from that tool. Sites the user approved for other reasons stay approved.
• Upgrades and removals are recorded as tool.upgraded and tool.disabled.

Choosing the default agent

The chat (Easy mode) uses one agent at a time. Levee picks it in this order; the first rule that gives an answer wins:

1. Policy. container.defaultAgentTool, for example "claude-code". When this is set, it is enforced: the Preferred agent setting in the app is locked and users cannot change it.
2. The user's preference, set in the app under Settings > Preferred agent.
3. Built-in order: Claude Code, then Codex CLI.
4. The only chat-capable tool in the catalog, if there is just one.

When several versions of the chosen tool are in the catalog, the highest version is used for new projects.

If policy names a tool that is not in the catalog (or cannot chat), Levee does not fall back to another agent: chat is unavailable until that tool is added. This makes an enforced choice reliable.

{
  "container": {
    "defaultAgentTool": "claude-code"
  }
}

Does the agent ask before acting inside the sandbox?

No, not in the chat. AI agents usually ask before running a command or changing a file. In Levee's chat, those requests are approved automatically, because the sandbox is the boundary: whatever the agent does inside it cannot reach anything policy does not allow. Each such approval is recorded in the audit trail. Requests that would leave the sandbox (a new website, a model that needs approval, a search query) still come to the user through Levee's own approval prompts.

In the terminal (Console), the agent runs as it would on a normal computer, with its own prompts and settings.

Signing in to the agent's vendor

Some tools support their vendor's own sign-in (for example a subscription account) as well as API keys. In Levee, the recommended setup is to route model calls through Model Access, so that the organization's key or the Vediram LLM Gateway is used and no personal credential enters the sandbox.