Management which domains your AI brokers can entry

AI brokers that may browse the online open highly effective prospects—from analysis automation to real-time information gathering. Nevertheless, giving an AI agent unrestricted web entry raises safety and compliance issues. What if the agent accesses unauthorized web sites? What if delicate information is exfiltrated to exterior domains?

Amazon Bedrock AgentCore gives managed instruments that allow AI brokers to work together with the online (Browser), execute code (Code Interpreter), and host brokers (Runtime). When deployed in an Amazon Digital Non-public Cloud (Amazon VPC), you possibly can management device community entry utilizing AWS Community Firewall to implement domain-based filtering. AWS Community Firewall additionally gives you with managed guidelines to assist cut back entry to botnets, known-malware domains, and different high-risk sources.

On this publish, we present you how you can configure AWS Community Firewall to limit AgentCore sources to an allowlist of accredited web domains. You should use this structure to:

• Allow entry solely to specified domains (for instance, wikipedia.org, stackoverflow.com)
• Explicitly block sure classes (e.g., social media websites) utilizing rule templates
• Log the connection makes an attempt for audit and compliance alignment
• Apply a default-deny coverage for unspecified domains

This publish focuses on domain-level filtering utilizing SNI inspection — the primary layer of a defense-in-depth method. For DNS-level filtering and content material inspection methods, see Going additional on the finish of this publish. For inbound entry management (proscribing who can invoke your brokers), you can too see Useful resource-based insurance policies for Amazon Bedrock AgentCore. These help situations like aws:SourceIp, aws:SourceVpc, and aws:SourceVpce. These controls are complementary layers in a protection in depth technique.

Why this issues: Enterprise safety necessities

Prospects deploying AI brokers in regulated industries have constant safety necessities round community ingress and egress management:

Enterprise organizations with excessive safety necessities

Prospects in regulated industries conducting safety opinions for AI agent deployments constantly ask about community isolation and egress management, requiring detailed explanations of how agent visitors is managed and audited. These clients need assurance that agent runtime endpoints stay non-public, and that extra safety controls like internet software firewall protections can be found.

Multi-tenant SaaS suppliers

Enterprise software program as a service (SaaS) suppliers require DNS-level allowlisting and denylisting as a result of their multi-tenant architectures want per-customer community insurance policies. For instance, Buyer A would possibly want to permit domains that Buyer B blocks. Widespread necessities embrace:

• Execution-specific blocking (stop entry to sure domains throughout particular browser launches)
• Regional restrictions (block web site classes in particular areas)
• Class-based guidelines (disable playing or social media websites by way of pre-packaged rule units)

Safety vulnerability mitigation and compliance audit necessities

Safety groups evaluating AI brokers have recognized that brokers might be tricked into navigating to unintended websites by way of immediate injection assaults. Customized URL allowlists cut back the assault floor by proscribing the browser to accredited domains, no matter what the agent is instructed to do. Area-based egress filtering gives the logging and entry management visibility that safety groups usually want for his or her safety monitoring processes.

Resolution overview

The answer deploys AgentCore Browser in a non-public subnet with no direct web entry. The outbound visitors routes by way of AWS Community Firewall, which inspects TLS Server Identify Indication (SNI) headers to find out the vacation spot area and apply filtering guidelines. You may as well monitor Community Firewall actions taken to limit visitors by way of the native Community Firewall integration with Amazon CloudWatch metrics.

Determine 1: AgentCore deployment with AWS Community Firewall and domain-based egress filtering

The structure consists of:

• Non-public subnet: Hosts AgentCore Browser situations with no public IP addresses
• Public subnet: Incorporates the NAT Gateway for outbound connectivity
• Firewall subnet: Hosts the Community Firewall endpoint
• 4 route tables: Management visitors stream by way of the firewall for each outbound requests and return visitors

Visitors stream

1. AgentCore Runtime executes the agent and invokes the AgentCore Browser device
2. AgentCore Browser initiates an HTTPS request from the non-public subnet
3. The non-public subnet route desk directs visitors to the NAT Gateway within the public subnet
4. The NAT Gateway interprets the non-public IP deal with and forwards the request to the Community Firewall endpoint
5. Community Firewall inspects the TLS SNI header to determine the vacation spot area
6. If the area matches an allowlist rule, the firewall forwards visitors to the Web Gateway
7. The Web Gateway routes accredited visitors to the exterior vacation spot
8. Return visitors follows the symmetric path again by way of the firewall to the agent

This structure helps make it possible for the browser visitors is inspected and filtered, whatever the vacation spot.

Word: SNI-based filtering helps management which domains brokers hook up with on the TLS layer. For DNS-level management, together with controls to assist stop DNS tunneling and exfiltration, pair this with Amazon Route 53 Resolver DNS Firewall. DNS Firewall helps deal with a limitation of SNI inspection: an agent might probably resolve a blocked area by way of DNS and join by IP deal with straight.

Stipulations

Earlier than you start, just remember to have:

• An AWS account with permissions to create VPC sources, Community Firewall, and IAM roles
• AWS Command Line Interface (AWS CLI) model 2.x configured with applicable credentials
• Entry to Amazon Bedrock AgentCore
• Fundamental familiarity with VPC networking ideas

Walkthrough

For the whole step-by-step VPC and Community Firewall setup, see the Amazon Bedrock AgentCore VPC configuration documentation.

This part highlights the AgentCore Browser-specific configuration.

Step 1: Deploy sources utilizing the CloudFormation template

Launch the CloudFormation template from the repository. You possibly can maintain the stack default values. Nevertheless, ensure that so as to add a stack title (for instance, “agentcore-egress“) to the “Stack title” subject, select an Availability Zone on the “Availability Zone” menu, and embrace a sound present bucket title on the “BucketConfigForOutput” parameter. Anticipate the stack creation to finish, which generally takes 10 minutes. Proceed with the next steps after the stack standing modifications to CREATE_COMPLETE.

Step 2: Evaluate the IAM execution position

AgentCore Browser requires an IAM position with a belief coverage for the Amazon bedrock-agentcore.amazonaws.com service:

{
“Model”: “2012-10-17”,
“Assertion”: [
{
“Effect”: “Allow”,
“Principal”: {
“Service”: “bedrock-agentcore.amazonaws.com”
},
“Action”: “sts:AssumeRole”
}
]
}

Step 3: Configure the Community Firewall allowlist

Create a stateful rule group along with your accredited domains. Word the main dot (.) to match subdomains:

cat > allowlist-rules.json << ‘EOF’
{
“RulesSource”: {
“RulesSourceList”: {
“Targets”: [
“.wikipedia.org”,
“.stackoverflow.com”,
“.docs.aws.amazon.com”,
“.amazonaws.com”,
“.pypi.org”,
“.pythonhosted.org”
],
“TargetTypes”: [“HTTP_HOST”, “TLS_SNI”],
“GeneratedRulesType”: “ALLOWLIST”
}
},
“StatefulRuleOptions”: {
“RuleOrder”: “STRICT_ORDER”
}
}
EOF

aws network-firewall create-rule-group
–rule-group-name browser-allowed-domains
–type STATEFUL
–capacity 100
–rule-group file://allowlist-rules.json
–region us-east-2

Essential: Embody .amazonaws.com in your allowlist if the browser requires AWS service entry or use VPC Endpoints in its place.

Safety consideration: The .amazonaws.com area is a broad allowlist that allows entry to hosted endpoints on AWS, together with public Amazon Easy Storage Service (Amazon S3) buckets, Amazon API Gateway endpoints, and AWS Lambda perform URLs. For tighter management, use VPC Endpoints for AWS service entry and allowlist solely the precise exterior domains your brokers want.

For Code Interpreter: Think about including “.pypi.org” and “.pythonhosted.org” in case you want a pip package deal set up. Commonest packages are pre-installed, making these domains non-compulsory to your use case.

Step 4: Configure the firewall coverage

The firewall coverage should use aws:drop_established because the default motion. This permits TCP handshakes to finish (required for TLS SNI inspection) whereas dropping connections to non-allowed domains:

cat > firewall-policy.json << ‘EOF’
{
“StatelessDefaultActions”: [“aws:forward_to_sfe”],
“StatelessFragmentDefaultActions”: [“aws:forward_to_sfe”],
“StatefulRuleGroupReferences”: [
{
“ResourceArn”: “arn:aws:network-firewall:us-east-2:ACCOUNT_ID:stateful-rulegroup/browser-allowed-domains”,
“Priority”: 1
}
],
“StatefulEngineOptions”: {
“RuleOrder”: “STRICT_ORDER”
},
“StatefulDefaultActions”: [“aws:drop_established”]
}
EOF

Don’t use aws:drop_strict as a result of it blocks TCP SYN packets earlier than the TLS handshake, stopping SNI inspection.

Step 5: Create the safety group

Create a safety group that permits outbound visitors. The Community Firewall handles area filtering, so the safety group permits the egress:

# Create safety group
aws ec2 create-security-group
–group-name agentcore-egress-sg
–description “AgentCore instruments – egress solely, filtered by Community Firewall”
–vpc-id vpc-XXXXXXXXX
–region us-east-2

# Enable all outbound visitors (Community Firewall handles filtering)
aws ec2 authorize-security-group-egress
–group-id sg-XXXXXXXXX
–protocol -1
–port -1
–cidr 0.0.0.0/0
–region us-east-2

# Take away default inbound guidelines if current (AgentCore instruments do not want inbound)
aws ec2 revoke-security-group-ingress
–group-id sg-XXXXXXXXX
–protocol -1
–port -1
–cidr 0.0.0.0/0
–region us-east-2

Step 6: Create the AgentCore Browser

Create the browser with VPC configuration pointing to your non-public subnet:

aws bedrock-agentcore-control create-browser
–name my_secure_browser
–execution-role-arn arn:aws:iam::ACCOUNT_ID:position/AgentCoreBrowserExecutionRole
–network-configuration ‘{
“networkMode”: “VPC”,
“vpcConfig”: {
“securityGroups”: [“sg-XXXXXXXXX”],
“subnets”: [“subnet-XXXXXXXXX”]
}
}’
–region us-east-2

Step 6b: Create AgentCore Code Interpreter (Non-compulsory)

You may as well deploy AgentCore Code Interpreter in the identical VPC with the identical firewall safety:

aws bedrock-agentcore-control create-code-interpreter
–name my_secure_code_interpreter
–network-configuration ‘{
“networkMode”: “VPC”,
“vpcConfig”: {
“securityGroups”: [“sg-XXXXXXXXX”],
“subnets”: [“subnet-XXXXXXXXX”]
}
}’
–region us-east-2

AgentCore Code Interpreter makes use of the identical community path as Browser. In case you want pip to put in packages, ensure that .pypi.org and .pythonhosted.org are in your allowlist.

Step 6c: Deploy agent on AgentCore Runtime (Non-compulsory)

For container-based agent deployments, use the identical VPC configuration:

aws bedrock-agentcore-control create-agent-runtime
–agent-runtime-name my_vpc_agent
–role-arn arn:aws:iam::ACCOUNT_ID:position/AgentCoreRuntimeRole
–agent-runtime-artifact ‘{
“containerConfiguration”: {
“containerUri”: “ACCOUNT_ID.dkr.ecr.us-east-2.amazonaws.com/my-agent:newest”
}
}’
–network-configuration ‘{
“networkMode”: “VPC”,
“networkModeConfig”: {
“securityGroups”: [“sg-XXXXXXXXX”],
“subnets”: [“subnet-XXXXXXXXX”]
}
}’
–protocol-configuration ‘{“serverProtocol”: “HTTP”}’
–region us-east-2

AgentCore Runtime area necessities rely in your mannequin supplier. Embody .amazonaws.com for Amazon Bedrock mannequin API calls or add the suitable domains for different mannequin suppliers your agent makes use of. Moreover, permit customized domains that your agent should entry.

Step 7: Take a look at the Configuration

Begin a browser session and confirm that the firewall guidelines work accurately:

# Begin browser session
aws bedrock-agentcore start-browser-session
–browser-identifier my_secure_browser-ABC123xyz
–region us-east-2

Use the returned WebSocket URL with a browser automation device like Playwright to check each allowed and blocked domains:

# test_firewall_rules.py

from playwright.sync_api import sync_playwright
import boto3
from botocore.auth import SigV4Auth
from botocore.awsrequest import AWSRequest

WEBSOCKET_URL = “wss://your-session-url” # From start-browser-session response
REGION = “us-east-2″

# Signal the WebSocket URL with SigV4
session = boto3.Session(region_name=REGION)
credentials = session.get_credentials().get_frozen_credentials()
request = AWSRequest(technique=”GET”, url=WEBSOCKET_URL.substitute(“wss://”, “https://”))
SigV4Auth(credentials, “bedrock-agentcore”, REGION).add_auth(request)
headers = dict(request.headers)

def test_domain(web page, url, expected_success):
strive:
response = web page.goto(url, timeout=10000)
success = response and response.standing < 400
standing = “PASS” if success == expected_success else “FAIL”
print(f”{standing}: {url} – {‘loaded’ if success else ‘blocked’}”)
return success == expected_success
besides Exception as e:
success = False
standing = “PASS” if not expected_success else “FAIL”
print(f”{standing}: {url} – blocked ({kind(e).__name__})”)
return not expected_success

with sync_playwright() as p:
browser = p.chromium.connect_over_cdp(WEBSOCKET_URL, headers=headers)
web page = browser.new_page()

# Take a look at allowed domains (ought to load)
test_domain(web page, “https://wikipedia.org”, expected_success=True)
test_domain(web page, “https://docs.aws.amazon.com”, expected_success=True)

# Take a look at blocked domains (ought to timeout/fail)
test_domain(web page, “https://instance.com”, expected_success=False)
test_domain(web page, “https://twitter.com”, expected_success=False)

browser.shut()

Anticipated outcomes:

• Allowed domains (.wikipedia.org, .amazonaws.com) ought to load efficiently.
• Blocked domains ought to day out after the TCP handshake or return connection errors.

Word: Some allowed domains like docs.aws.amazon.com depend upon CDN sources from domains comparable to awsstatic.com and cloudfront.web. If pages on allowed domains fail to render absolutely, add the required CDN domains to your allowlist.

You may as well test the firewall logs in CloudWatch for blocked connection makes an attempt:

# View current alert logs (blocked connections)
aws logs filter-log-events
–log-group-name “/aws/network-firewall/agentcore-egress/alerts”
–filter-pattern ‘{ $.occasion.alert.motion = “blocked” }’
–region us-east-2
–start-time $(($(date +%s) – 300))000

# Confirm firewall sync standing earlier than testing
aws network-firewall describe-firewall
–firewall-name agentcore-egress-firewall
–region us-east-2
–query ‘FirewallStatus.ConfigurationSyncStateSummary’

Troubleshooting: If allowed domains are blocked, confirm:

1. Firewall sync standing exhibits IN_SYNC (rule modifications take a couple of minutes)
2. Area entries embrace the main dot (.wikipedia.org not wikipedia.org)
3. Route tables are configured accurately for symmetric routing
4. In case you obtain HTTP 403 errors on allowed domains, that is usually bot detection by the vacation spot website, not a firewall block. Verify CloudWatch ALERT logs to substantiate—blocked connections can have specific alert entries.

Greatest practices

• Use STRICT_ORDER analysis: This facilitates predictable rule processing when combining allowlists and denylists.
• Embody .amazonaws.com for AWS service entry: Or use VPC Endpoints to keep away from routing AWS API calls by way of the web.
• Configure the IGW ingress route desk: That is crucial for symmetric routing. With out it, return visitors bypasses the firewall.
• Allow each ALERT and FLOW logs: ALERT logs seize blocked connections; FLOW logs present connection metadata for the visitors.
• Anticipate firewall sync: Rule modifications take a couple of minutes to propagate. Confirm ConfigurationSyncStateSummary: IN_SYNC earlier than testing.
• Configure HOME_NET for multi-VPC architectures: By default, Community Firewall area inspection solely filters visitors originating from the deployment VPC’s Classless Inter-Area Routing (CIDR) vary. In case you use a centralized firewall with AWS Transit Gateway to examine visitors from a number of VPCs, you have to configure the HOME_NET variable in your rule group to incorporate the supply CIDR ranges. With out this, visitors from different VPCs can bypass area filtering.

Limitations and price concerns

• Content material inspection requires TLS inspection: By default, area filtering operates on unencrypted TLS metadata (SNI headers) and may’t examine encrypted request or response our bodies. To examine HTTPS content material, allow TLS inspection in your Community Firewall and add Suricata guidelines that match on HTTP physique content material. SNI/Host header bypass danger: Community Firewall makes use of TLS SNI headers and HTTP Host headers—not IP addresses—to find out vacation spot domains. If these headers are manipulated, visitors might bypass area filtering. For top-security deployments, mix area guidelines with IP-based guidelines for crucial blocked locations, or add DNS filtering as a further layer. Moreover, contemplate pairing SNI-based guidelines with Route 53 DNS Firewall to assist stop brokers from resolving blocked domains by way of DNS and connecting by IP deal with straight.
• HOME_NET scope in multi-VPC deployments: By default, Community Firewall area inspection solely applies to visitors originating from the deployment VPC’s CIDR vary. In case you use a centralized firewall with AWS Transit Gateway (a number of VPCs routing by way of a shared firewall), you have to configure the HOME_NET variable in your rule group to incorporate the supply CIDR ranges. With out this, visitors from spoke VPCs bypasses area inspection. See Stateful area listing rule teams for particulars.
• Prices will range primarily based in your utilization. See NAT Gateway pricing and Community Firewall pricing for present charges.

Clear up

Delete sources on this order to keep away from ongoing expenses:

1. Delete the AgentCore Browser
2. Delete the Community Firewall (disable safety settings first)
3. Delete the NAT Gateway
4. Launch the Elastic IP deal with
5. Delete the subnets and route tables
6. Detach and delete the Web Gateway
7. Delete the VPC

Word: AgentCore Browser and Code Interpreter create elastic community interfaces in your VPC. After deleting these sources, wait a couple of minutes for the community interface to launch earlier than deleting the safety group, subnet, or VPC. If deletion fails, test for lingering community interfaces within the subnet and watch for them to detach.

Associated sources

For extra info, see the next sources.

Going additional

Area filtering by way of SNI inspection is one layer of egress safety. Relying in your necessities, contemplate these extra mitigations:

Approach
What it does
Helps in eventualities the place
Reference

Route 53 DNS Firewall
Helps block or permit DNS queries by area and forestall DNS tunneling and exfiltration.
You want DNS-level filtering or safety in opposition to DNS-based information exfiltration.
Shield in opposition to superior DNS threats

TLS inspection + Suricata DLP
Decrypt HTTPS, examine request/response our bodies with Suricata guidelines, assist block delicate information patterns (PII, credentials).
You want information loss prevention (DLP) for agent-generated visitors.
TLS inspection for encrypted egress visitors

Centralized inspection structure
Route visitors from a number of VPCs by way of a shared inspection VPC with Community Firewall.
You run a number of AgentCore deployments and wish centralized coverage enforcement.
Deploy centralized visitors filtering

When utilizing TLS inspection, configure customized certificates in your AgentCore sources to belief the Community Firewall’s re-signing CA.

Conclusion

By combining Amazon Bedrock AgentCore instruments with AWS Community Firewall, you may give AI brokers managed internet entry whereas sustaining safety and compliance alignment. The domain-based filtering method helps you outline exactly which web sites brokers can entry, block undesirable locations, and log the connection makes an attempt for audit functions. This structure addresses the safety issues raised by enterprise clients:

• FSI compliance: Gives the community isolation and audit logging required for CISO-level safety opinions.
• Multi-tenant management: Permits per-customer or per-execution area insurance policies for SaaS suppliers.
• Immediate injection protection: Restricts agent navigation to accredited domains, serving to cut back the assault floor for immediate injection.
• Audit proof: Generates CloudWatch logs that help compliance audit necessities.

For enterprises deploying AI brokers that want web entry for analysis, information gathering, or API integrations, this sample gives a production-ready method to sustaining strict management over the place that entry leads. Quite than sustaining customized squid proxies or advanced community infrastructure, you should utilize AWS managed providers to implement enterprise-grade egress filtering in hours, not weeks.

For extra details about AgentCore Browser, see the AgentCore Browser documentation.

In regards to the authors

Kosti Vasilakakis

Kosti Vasilakakis is a Principal PM at AWS on the Agentic AI staff, the place he has led the design and improvement of a number of Bedrock AgentCore providers from the bottom up, together with Runtime, Browser, Code Interpreter, and Identification. He beforehand labored on Amazon SageMaker since its early days, launching AI/ML capabilities now utilized by hundreds of corporations worldwide. Earlier in his profession, Kosti was a knowledge scientist. Outdoors of labor, he builds private productiveness automations, performs tennis, and enjoys life along with his spouse and children.

Evandro Franco

Evandro Franco is a Sr. Information Scientist engaged on Amazon Net Companies. He’s a part of the World GTM staff that helps AWS clients overcome enterprise challenges associated to AI/ML on prime of AWS, primarily on Amazon Bedrock AgentCore and Strands Brokers. He has greater than 18 years of expertise working with expertise, from software program improvement, infrastructure, serverless, to machine studying. In his free time, Evandro enjoys enjoying along with his son, primarily constructing some humorous Lego bricks.

Kevin Orellana

Kevin Orellana is a Software program Growth Engineer at Amazon Net Companies on the Bedrock AgentCore staff, primarily based in Seattle. He builds and operates core infrastructure powering agentic AI capabilities, together with Browser, Code Interpreter, and Runtime. Earlier in his profession, Kevin labored on the Bedrock inference staff internet hosting frontier fashions. In his free time, he enjoys climbing along with his Goldendoodle, experimenting with multi-agent simulations, and dealing towards constructing a private AI assistant that speaks English, Spanish, and Mandarin.

Yan Marim

Yan Marim is a Sr. GenAI Specialist Options Architect at Amazon Net Companies, primarily based in Brazil. As a part of the LATAM Specialist staff, he guides clients by way of their generative AI adoption journey, specializing in Amazon Bedrock and agentic AI options. In his free time, Yan enjoys spending high quality time along with his spouse and canine, and watching soccer video games.