Web Access

Control which websites and APIs the agent can reach over HTTP and HTTPS, with per-domain rules, method filters, approvals and TLS inspection

Web access decides which websites and online services the agent may reach. By default it can reach none. You list the sites to allow, the sites to block, and the sites where the user is asked first. A refused request gives the agent a plain "Access denied.", and every decision is recorded in the audit trail.

There is no other way out of the sandbox: Windows network enforcement blocks any traffic from the sandbox that does not go through Levee, including tools that ignore proxy settings.

Web access is configured in the proxies.http section of policy.

Section shape

A default decision, plus an ordered list of rules. The first rule that matches a request decides.

{
  "proxies": {
    "http": {
      "default": "deny",
      "rules": [
        { "domain": "api.anthropic.com", "ports": [443], "action": "allow" },
        { "domain": "learn.microsoft.com", "action": "allow" },
        { "domain": "www.ecb.europa.eu", "action": "allow" },
        { "domain": "api.example-vendor.com", "action": "allow", "inspect": true },
        { "domain": "*.wikipedia.org", "action": "escalate" },
        { "domain": "pastebin.com", "action": "deny" }
      ]
    }
  }
}

If the section is missing, the agent has no web access at all.

Rule keys

Actions

escalate is useful as a default for pilot groups ("default": "escalate"): users can unblock the hosts they genuinely need, and the audit trail tells you which hosts to add to the allow list later.

Domain matching

• Matching is case-insensitive, and a trailing dot is ignored.
• example.com matches exactly example.com, not its subdomains.
• *.example.com matches any subdomain at any depth (api.example.com, a.b.example.com) but not example.com itself. To cover both, write two rules.
• Internationalized domain names are compared in their ASCII (punycode) form, so a look-alike Unicode host cannot match a rule written for an ASCII host.

Method filters

methods limits a rule to some kinds of request, and it only works for plain-HTTP sites. For example, to let reads from a plain-HTTP service through and have the user approve anything else:

{ "domain": "reports.example.com", "ports": [80], "action": "allow", "methods": ["GET", "HEAD"] },
{ "domain": "reports.example.com", "ports": [80], "action": "escalate" }

Because a method mismatch falls through to the next rule, the second rule decides every other method.

Keep in mind:

• HTTPS sites are matched once per connection, as CONNECT, with or without TLS inspection. A rule limited to GET or HEAD never matches an HTTPS site, so the site falls through to the next rule or the default. Leave methods out of rules for HTTPS sites.
• A method filter does not stop data leaving. A GET request can still carry data in its address and headers. To keep data away from a site, do not allow it.

Protections that always apply

Some checks cannot be turned off, whatever the rules say. For example, the agent can never reach your internal network or the computer itself through web access. The following checks apply on top of your rules.

What does the agent see when a request is refused?

The same answer every time. Every refusal looks the same, whatever the reason (policy, the user said no, private address, mismatched host name, audit trail unavailable):

HTTP/1.1 403 Forbidden
Content-Type: text/plain

Access denied.

This is deliberate: an agent that could tell the reasons apart could use the differences to map your network or your policy. The actual reason is always in the audit trail. See Agent gets "Access denied.".

TLS inspection

Inspection lets Levee look inside encrypted traffic to one site, so rules can check more than the site name. It is off by default; turn it on only where you need it.

By default Levee checks the destination of an HTTPS connection (host name and port) but does not decrypt it. The content stays end-to-end encrypted between the agent and the website.

Setting "inspect": true on a rule makes Levee decrypt and re-encrypt traffic for that host, so it can record each request (method, path, content type and size) in the audit trail. The allow or deny decision is still made once per connection, from the host name. To make this possible, every sandbox trusts a Levee certificate authority that is generated for the session and never leaves the computer. The agent finds it through the standard SSL_CERT_FILE, NODE_EXTRA_CA_CERTS, REQUESTS_CA_BUNDLE, CURL_CA_BUNDLE and GIT_SSL_CAINFO variables and the sandbox's certificate store.

Use inspection selectively:

• Certificate-pinned clients break. A tool that only accepts its vendor's own certificate will refuse an inspected connection. Leave inspect off for such hosts.
• Tools with their own trust store (some Java or Python environments) may need to be pointed at the certificate in C:\certs.
• Inspection adds processing on the computer. There is no need to inspect hosts where a host-level decision is enough.

Corporate proxies

Levee works behind your corporate proxy, as long as the proxy does not ask for a sign-in. If your computers reach the internet through a corporate proxy, Levee's web access forwards allowed traffic to it using the Windows system proxy configuration, including PAC scripts. Keep in mind:

• The proxy configuration is read when a project starts. After changing proxy or PAC settings, stop and start running projects.
• Upstream proxies that require authentication are not supported. Exempt the computer (or Levee traffic) from proxy authentication, or allow the destinations directly.
• If the corporate proxy refuses a connection, the agent sees the same Access denied. response and the reason is recorded in the audit trail.

The agent's own proxy settings inside the container (HTTP_PROXY, HTTPS_PROXY) always point at Levee. You do not configure your corporate proxy inside the sandbox.

How do tools, approvals and plugins interact with rules?

Approvals and tools never override a rule that denies a site. In detail:

• Turning on an AI tool in a project asks the user to approve the hosts that tool needs (for example the vendor's API). That approval is remembered for the project and answers future approval prompts for those hosts. It does not override your policy: if a rule denies one of the hosts, the tool cannot be turned on (Blocked by admin policy: <hosts>), and if the hosts resolve to deny by default, the tool will not reach them. Allow the hosts, or use escalate. See AI Tools.
• Remembered approvals ("Remember this decision" in the approval prompt) only answer requests that policy sends for approval. They never turn a deny into an allow. A remembered decision belongs to one project folder and to the user who started the project, and Levee stores it where only the system can read it. Users can review and revoke them in the project's Access Policy tab.
• Model traffic (the agent's calls to Anthropic or OpenAI APIs) goes through Model Access, not through these rules. Tools can still need web access to their vendor for sign-in, updates, and telemetry, which is why their required hosts are listed.
• Plugins reach only the sites their own definition declares, on port 443, through Levee's web channel. See Plugins.

Recipes

Ready-made rules for common needs. Combine the ones you need in rules.

Claude Code

Claude Code sends its model calls through Model Access. It also needs web access to Anthropic for its own services:

{ "domain": "api.anthropic.com", "action": "allow" },
{ "domain": "cdn.anthropic.com", "action": "allow" }

Reference sites, others on request

{ "domain": "learn.microsoft.com", "action": "allow" },
{ "domain": "www.ecb.europa.eu", "action": "allow" }

With "default": "escalate", any other site asks the user.

Public package registries

Scripts in Python or JavaScript often download add-on libraries, called packages. These rules let the agent reach the public registries:

{ "domain": "registry.npmjs.org", "action": "allow" },
{ "domain": "pypi.org", "action": "allow" },
{ "domain": "files.pythonhosted.org", "action": "allow" },
{ "domain": "api.nuget.org", "action": "allow" }

Web access cannot make an HTTPS registry download-only. For download-only access and per-package allow lists, see Packages (Preview).

Internal package mirror (Artifactory, Nexus)

Your mirror must be reachable on a public address from the computer's point of view, because private addresses are always refused. If your mirror has only an internal address, contact Vediram support to discuss options.

{ "domain": "artifactory.example.com", "action": "allow" }

Downloading from GitHub

{ "domain": "github.com", "action": "allow" },
{ "domain": "api.github.com", "action": "allow" },
{ "domain": "codeload.github.com", "action": "allow" },
{ "domain": "*.githubusercontent.com", "action": "allow" }

git clone https://github.com/... works with these rules. SSH (port 22) is not web traffic, so Git over SSH does not work inside the sandbox; use HTTPS addresses.

The network section

You do not need to write it. Older examples may show a top-level network section. The rules that are enforced are the ones in proxies.http. On cloud-managed devices, proxies.http is generated from the Portal's Allowed hosts and HTTP rules; see Managing Policy in the Vediram Portal.

Audit

Each request produces audit events such as http.request (allowed), http.denied (with the reason), http.access_requested and http.access_approved (approvals), and security events such as http.security.dns_rebind (private address refused) and http.security.sni_mismatch (host name mismatch). See Audit Event Reference.