Locking down AI agents: Claude's new domain restrictions

Anthropic cleared a large part of its beta shelf on 19 August 2026. The computer use tool left beta as the computer_toolset_20260801 toolset, a new browser use tool launched as browser_toolset_20260801, and the Files API, Agent Skills and the Skills API, and the Admin API user-management endpoints for Claude Enterprise all reached production status on the Claude API. Tucked into the same release notes is the item that matters most for anyone accountable for agent governance: you can now restrict which sites a Claude Managed Agents agent's web_search and web_fetch tools can reach, using allowed_domains and blocked_domains lists, plus a max_content_tokens cap on fetched content and a user_location setting for search localisation.

For Swedish and EU enterprise teams this release lands at a useful moment. Many organisations spent the first half of 2026 piloting agents and are now writing the internal policies that decide whether those pilots go to production. Two of the standard blockers in that conversation are "the vendor calls this a beta" and "we cannot control where the agent browses". This release removes both, at least for teams building on the Claude API. Below is what changed, how the domain restrictions actually behave, and a decision guide for using them in a governance-friendly agent design.

What moved to production on 19 August

Computer use and the new browser use tool

Computer use, the tool that lets Claude drive a desktop through screenshots and clicks, is out of beta as computer_toolset_20260801. No beta header is required, the toolset supports batch actions so the model can execute several UI actions in one turn, zoom is enabled by default, and per-member configuration flows through a configs array. Upgrading from the computer_20251124 beta changes the request shape and tool handling, so treat it as a small migration rather than a header deletion.

Browser use (browser_toolset_20260801) is new, not a rename. It is a client toolset for driving a browser that your own application hosts. Instead of treating the screen as pixels, it reads the page itself: the accessibility tree, elements, forms and tabs. On top of screenshot-and-click control it adds element references, structured form input, tab management, download reporting and opt-in file upload. For web-heavy automation this is the better abstraction, and because your application hosts the browser, the session runs inside infrastructure you control. That detail matters for EU teams: the browser, its cookies and everything it downloads stay on your side.

Both toolsets are available on Claude Fable 5, Claude Mythos 5, Claude Opus 5, Claude Sonnet 5 and Claude Opus 4.8 on the Claude API.

Files API and Agent Skills leave beta

The Files API no longer requires the files-api-2025-04-14 beta header, on the /v1/files endpoints and on Messages API requests that reference uploaded files. Requests without the header get the current behaviour: file expiration through expires_in_seconds at upload (file objects report expires_at), page and next_page pagination, and an ids[] filter on listing. Agent Skills and the Skills API (/v1/skills) similarly drop the skills-2025-10-02 header, including for Messages API requests that load Skills through the container parameter.

File expiration deserves a second look from a GDPR standpoint. If your agents upload documents that contain personal data, expires_in_seconds gives you an enforcement mechanism for retention limits at the storage layer rather than in a cleanup script you hope runs. Set it at upload time as a matter of policy.

Enterprise user management stabilises

The Admin API user-management endpoints for Claude Enterprise organisations, covering members, invites, groups and custom roles, are out of beta. The ce-user-management-2026-07-13 header is no longer required. If you provision Claude access from your identity tooling, the API surface you scripted against is now a stable contract. Across all four graduations the superseded beta headers are still accepted and behave as before, so nothing breaks on upgrade day, but plan the cleanup anyway (checklist below).

Domain restrictions: the control governance teams have been asking for

Until now, a Claude Managed Agents agent with web_search and web_fetch enabled could reach anything Anthropic's search and fetch providers could reach. For a research assistant that is a feature. For an agent that handles internal documents, it is the line item your security review flags: an agent that can read arbitrary web content is an agent with a prompt-injection ingress and a potential exfiltration egress.

The new settings close that gap per tool. On the agent's agent_toolset_20260401 configuration, each of web_search and web_fetch takes its own allowed_domains (the only hosts the tool may reach) or blocked_domains (hosts it may never reach). The two lists are mutually exclusive on a single entry, and each holds between 1 and 64 domains. A configuration looks like this:

{
  "type": "agent_toolset_20260401",
  "configs": [
    {
      "name": "web_search",
      "allowed_domains": ["learn.microsoft.com", "anthropic.com"],
      "user_location": {
        "type": "approximate",
        "country": "SE",
        "timezone": "Europe/Stockholm"
      }
    },
    {
      "name": "web_fetch",
      "allowed_domains": ["learn.microsoft.com"],
      "max_content_tokens": 50000
    }
  ]
}

The enforcement semantics differ by tool, and the difference is worth internalising. A web_fetch call to a URL outside the lists returns an error result to the agent: is_error is true on the agent.tool_result event and the content names the url_not_allowed error code, so the model knows the fetch was refused and your event stream records it. web_search instead silently omits results the lists do not permit. One is a visible refusal, the other is a filtered view of the web.

The matching rules are strict and predictable, which is exactly what you want in a control you will cite in a security review:

A listed domain covers that host and all its subdomains: example.com covers docs.example.com, but docs.example.com does not cover example.com or api.example.com.
www counts as a subdomain like any other, so list the bare domain to cover both.
Plain hostnames only: no schemes, ports, wildcards or credentials. IP addresses are rejected in every form, as are bare TLDs, single-label names like intranet, and localhost-style hosts.
Internationalised domain names must be in Punycode (xn--) form.
web_fetch domains cannot carry a path. web_search domains can carry a limited path suffix, but Anthropic recommends plain hostnames because the search provider treats paths as URL patterns.

Validation happens when you create or update the agent, or a session that supplies tools, with descriptive 400 errors that name the offending list position. The session validates again when it first initialises the tool; if a setting stopped being valid in the meantime, the session emits a session.error event and returns to idle rather than retrying. You can also change the lists on an idle session mid-engagement by updating its tools, which makes staged tightening practical.

Do not confuse this with sandbox networking. An environment's networking settings govern the sandbox's own outbound traffic (what bash and your code can reach). They do not touch web_search or web_fetch, which execute on Anthropic's servers regardless of whether your sandbox is cloud-hosted or self-hosted. If your threat model says "the agent must only read approved sites", you need both controls: sandbox egress rules for code, and per-tool domain lists for the web tools. Organisation-level web settings in the Claude Console apply to the Messages API only, not to Managed Agents sessions.

Multiagent sessions: restrictions compose downward, never upward

In multiagent sessions every applicable domain list is enforced at once. Allowlists combine by intersection and blocklists add together, so a roster agent can narrow what its tools reach but can never widen beyond what the coordinator and any calling agent permit. If combined allowlists share no domain, the tool stays available but every call fails with url_not_allowed, and the tool description tells the model so. Keep roster allowlists inside the coordinator's list to avoid that dead end. This composition rule is the security property that makes delegation safe: a subagent cannot escalate its own web access, by design.

Allowlist or blocklist: a decision guide

Since one entry cannot set both lists, you must choose per tool. A workable rule set:

Agent touches internal or personal data? Allowlist, always. The exfiltration scenario to defend against is instructed browsing to an attacker-controlled URL with data smuggled into the query string. A blocklist cannot enumerate the internet; an allowlist does not have to.
Agent is a pure research assistant on public data? Blocklist is defensible. Block known-problematic hosts and let search quality do its job.
Documentation or support agent? Allowlist the handful of doc sites it needs. This also improves answer quality by removing low-grade sources from consideration.
Mixed needs? Split the roles across agents in a multiagent roster. Give the coordinator the widest acceptable allowlist and let each roster agent narrow further. The intersection rule enforces the hierarchy for you.
Remember the 64-domain cap. If your allowlist wants to be longer than 64 entries, that is usually a sign the agent's job is too broad for allowlisting, or that one bare domain should replace several subdomain entries.

Pair the lists with max_content_tokens on web_fetch. A cap keeps a single oversized page from flooding the context, which is both a cost control and a mild injection-surface control: less untrusted text in the window per fetch. And set user_location to Sweden for Swedish-facing agents; localised search results are a quality improvement you get for one config line.

The beta header cleanup

GA graduations accumulate as dead headers in your codebase. All four superseded headers are still accepted, and no sunset dates were published with this release, but requests that keep sending files-api-2025-04-14 get the older response format, so the cleanup has functional value beyond tidiness. Work through it deliberately:

1. Grep for computer_20251124, files-api-2025-04-14, skills-2025-10-02 and ce-user-management-2026-07-13 across services and infrastructure code.
2. For the Files API, removing the header changes response shapes: expiration fields and page/next_page pagination arrive. Update your pagination handling before deleting the header, not after.
3. For computer use, follow the computer_20251124 migration guide; the toolset request shape differs from the old tool definition.
4. For Skills and user management, header removal is close to a no-op, but retest the container-based Skill loading path.
5. Record the graduation in your vendor-risk documentation. "Production status per vendor release notes, 19 August 2026" is a sentence your procurement and audit colleagues can use.

The Swedish and EU angle

Governance documentation gets concrete. EU AI Act obligations for deployers lean on demonstrable oversight and risk controls, and GDPR data-minimisation arguments are easier when you can show technical enforcement rather than policy text. A domain allowlist is a citable technical measure: you can print the agent's configuration, show the url_not_allowed events in the session stream, and demonstrate that web reach is bounded by configuration your change-management process controls. That is a materially stronger answer in an internal audit than "the system prompt tells the agent not to".

Data residency has a companion control. Earlier in August, Anthropic added inference_geo to Managed Agents, letting you pin where model inference runs for an agent or a single session. Combined with self-hosted sandboxes for execution and now domain restrictions for web reach, the pieces exist to describe an agent deployment where inference geography, code execution and web access are each explicitly bounded. For teams answering Schrems-era transfer questionnaires, that is a diagram you can actually draw.

Procurement language changes. Swedish public-sector and regulated buyers routinely exclude beta functionality from what may be deployed in production, sometimes contractually. Computer use spent nearly two years in beta; as of this week it, browser use, Files, Skills and enterprise user management are production features with stable contracts. If a planned upphandling or internal platform decision stalled on beta status, the ground has shifted and the assessment is worth rerunning.

Azure-first teams: check your consumption path. These graduations are documented for the Claude API. Many Swedish enterprises consume Claude models through Microsoft Foundry instead, where feature availability can differ from Anthropic's first-party API. Managed Agents in particular is a Claude API product. If your architecture standard says "models via Foundry only", verify which of these capabilities exist on your path before promising them in a design document, or scope a deliberate exception for the agent platform while keeping model inference where your standard requires.

Before you flip anything on

Classify each agent by data sensitivity, then apply the allowlist/blocklist rule set above per tool, not per agent.
List bare domains, not www or deep subdomains, unless you intend the narrower match. Verify the subdomain coverage rules against what the agent actually needs.
Set max_content_tokens on web_fetch and user_location (country SE) on web_search as defaults in your agent templates.
Layer the controls: sandbox networking rules for code egress, domain lists for web tools, permission policies for tool approval. Each covers what the others do not.
Monitor url_not_allowed in your event stream. Frequent hits mean the allowlist is too tight for the task, or the agent is being steered somewhere it should not go. Both are worth knowing.
Schedule the beta header cleanup as a normal tech-debt ticket with the Files API pagination change called out.
Rerun stalled assessments that cited beta status, and re-verify feature availability on Microsoft Foundry if that is your mandated consumption path.