What domains should I add to my allowlist?

Author: PromptArmor LLM Threat Research Team

Published: May 13, 2026

How LLM sandboxes use domain allowlists

Modern agents run code inside sandboxes — containers, VMs, or browser environments — that determine what URLs a model can reach over the network via tools like 'web fetch' or 'curl'. Network egress is one of the most consequential controls in this sandbox: when a prompt injection succeeds, if an agent can't route traffic to an attacker-controlled domain, data exfiltration is likely to fail.

However, configuring a robust domain allowlist that still facilitates an agent's intended use cases requires nuance. In the preceding sections, we will describe how commonly allowlisted domains can yield data exfiltration vectors and how you can assess domains for risks before adding them to your allowlist.

Every major vendor exposes some form of domain allowlist. The mechanism, default policy, and configuration surface vary:

Common domains people allowlist — and the caveats

Three patterns we see frequently, and what to know about each before adding them:

1. registry.npmjs.org and npmjs.com

Why people add it: agents need to install Node.js packages to run builds, resolve dependencies, or scaffold code.

The caveat: npm accepts user-uploaded content — anyone with a free account can publish a package. A prompt injection can manipulate an agent into publishing sensitive data to an attacker-accessible package.

2. github.com and raw.githubusercontent.com

Why people add it: pulling repos, cloning dependencies, and fetching raw files in agent workflows.

The caveat: anyone can publish content on GitHub. A prompt injection can manipulate agents to upload user data to a public repository or gist. Additionally, attacker-controlled GitHub content can serve as C2 infrastructure to provide further poisoned instructions to a victim agent.

3. google.com, docs.google.com

Why people add it: organizations on Google Workspace use it for resources the agent should be able to access.

The caveat: docs.google.com also hosts Google Forms — and a Forms prefilled-submission URL (docs.google.com/forms/d/e//viewform?usp=pp_url&entry.=) lets an attacker exfiltrate data via an HTTP get request to an allowlisted domain. Furthermore, APIs allow additional data egress opportunities.

4. *.amazonaws.com, *.blob.core.windows.net, *.cloudapp.azure.com

Why people add it: a developer wants their agent to reach a specific S3 bucket, Azure Blob container, or Azure VM.

The caveat: over-permissive globbing yields exfiltration risks. Any AWS or Azure customer — including an attacker — can register a resource on the same parent domain. attacker.s3.amazonaws.com matches *.amazonaws.com, so a prompt injection can route exfiltration through the wildcard.

How to assess a domain before adding it to your allowlist

When evaluating whether to approve a domain, consider these principles:

Avoid over-permissive globbing. If a user needs access to one specific Azure service, e.g. <specific_tenant>.cloudapp.azure.com, approve that exact domain rather than *.azure.com. The wildcard parent gives attackers an obvious path: they register a VM with a custom DNS name and now control a site that matches the allowlist pattern.

Treat CDNs that may host untrusted content as risky. Popular hosting services that allow user-generated content are common malware-distribution and command-and-control surfaces. Adding them broadens both ingress (the agent can fetch attacker-authored content as if it were trusted) and egress (compromised code in the agent's environment can reach C2 infrastructure).

For data exfiltration concerns, ask:

• Is it a service that issues user-specific URLs that can be monitored?

  Ex: *.azure.com is problematic because a user can register a VM with a custom DNS name, yielding an attacker-controlled site of the form .cloudapp.azure.com.

  
  

• Is there an accessible API where an attacker could craft a prompt injection that manipulates an agent to submit content using an attacker-controlled API key?

  Any service that accepts authenticated writes becomes an exfiltration channel if the attacker can supply the credentials.

  
  

• Is there an accessible service where an attacker could craft a prompt injection that manipulates the agent to submit content to an attacker-controlled location?

  Ex. docs.google.com hosts Google Forms submission links, and submitting content to an attacker-controlled form yields exfiltration even though the parent domain is reputable.

  
  

• Is the domain itself controlled by an untrusted party?

  A personal website from an individual without an extensive history as a reputable party should not be on an allowlist used by an agent processing sensitive data.

The principle underlying all of these: a domain on an allowlist is a domain the agent will trust under prompt injection conditions. Add only what's required for the agent's actual job, scope it as narrowly as possible, and prefer denying everything else.