AWS showed how to restrict AgentCore AI agents' access to approved domains only

AWS released a practical guide on how to restrict internet access for AI agents at the domain level. This is not about a new model, but about a basic security measure: AgentCore resources can be configured to access only pre-approved sites.

Why This Is Needed

When an agent gains network access, the risk changes dramatically. Even if the model follows instructions well, it can still be given an undesirable URL, redirect, or external service that should not participate in the process. For corporate scenarios, this is a problem not only of security, but also of cost control, compliance with internal policies, and result predictability.

AWS suggests solving this problem at the network level rather than relying solely on prompts and application logic. In the published breakdown, the company shows how to set a domain allowlist for AgentCore resources through AWS Network Firewall. The idea is simple: an agent should not choose the entire internet itself if the business process requires working with a limited set of sources.

For teams building pipelines with AI agents on top of cloud infrastructure, this is also a matter of manageability. The narrower the external perimeter, the easier it is to handle incidents, verify compliance with security policy, and understand why the agent was able to access a particular resource. This approach is especially important where the AI agent is associated with internal data, customer documents, or automated actions.

How the Filter Works

At the center of the scheme is SNI, Server Name Indication. This parameter is sent at the start of a TLS connection and shows which domain the client wants to connect to. Network Firewall can analyze this field and compare it against a list of allowed domains. If the domain is in the allowlist, the connection goes through; if not, the request is blocked before the agent even begins to interact with the external resource.

This approach is useful where an agent needs access to several clear external network points: documentation, internal APIs through a public entry point, partner services, or specific SaaS platforms. In this scenario, security is built not around abstract "model trust," but around strictly defined network rules.

• Agent sees only an approved list of external domains
• New sites cannot be accessed without explicit rule updates
• Blocking occurs before business logic execution on the external resource
• Access policy is centralized in infrastructure rather than scattered across code
• Control becomes clearer for audit and internal security teams

Why This Is Not Enough

AWS separately emphasizes that domain-based filtering is only the first layer of defense. It reduces attack surface, but does not solve all risks associated with agents. If an approved domain itself serves harmful or unwanted content, the allowlist won't help. Similarly, this approach does not check what the agent does after connecting to an acceptable resource.

"Domain-level filtering through SNI checking is the first layer of

multi-layered defense."

There is also a more practical limitation: domain control sees the destination address but not the full intent of the request. It does not distinguish specific URL paths, parameters, operation types, and business context within the same allowed domain. Therefore, allowlist is good as a rough but very useful filter—especially at the internet entry point—however, it cannot be considered a complete policy for agent behavior.

The practical conclusion from this is: a network allowlist must be combined with other measures. These typically include environment isolation, minimal IAM rights, checking agent output actions, logging, tool limits, and additional application-level policies. In other words, Network Firewall answers "where the agent can go" but does not replace control over "what the agent does" and "what it brings back."

What This Means

AWS essentially formalizes a simple but important principle for agent systems: internet access should not be open by default but rather the minimum necessary. For companies testing AI agents in production, this is a good guideline: first restrict the external network to an approved domain list, then build deeper layers of protection.