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 considerations. 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 Personal Cloud (Amazon VPC), you may management instrument 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 assets.

On this put up, we present you how one can configure AWS Community Firewall to limit AgentCore assets to an allowlist of accredited web domains. You should utilize 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 put up focuses on domain-level filtering utilizing SNI inspection — the primary layer of a defense-in-depth strategy. For DNS-level filtering and content material inspection methods, see Going additional on the finish of this put up. For inbound entry management (limiting who can invoke your brokers), you may also see Useful resource-based insurance policies for Amazon Bedrock AgentCore. These help circumstances 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

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

Enterprise organizations with excessive safety necessities

Clients in regulated industries conducting safety opinions for AI agent deployments constantly ask about community isolation and egress management, requiring detailed explanations of how agent site visitors is managed and audited. These prospects need assurance that agent runtime endpoints stay non-public, and that further safety controls like internet utility 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 (forestall 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 via 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 via immediate injection assaults. Customized URL allowlists cut back the assault floor by limiting 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 typically 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 site visitors routes via AWS Community Firewall, which inspects TLS Server Identify Indication (SNI) headers to find out the vacation spot area and apply filtering guidelines. You can even monitor Community Firewall actions taken to limit site visitors via the native Community Firewall integration with Amazon CloudWatch metrics.

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

The structure contains:

• Personal subnet: Hosts AgentCore Browser situations with no public IP addresses
• Public subnet: Accommodates the NAT Gateway for outbound connectivity
• Firewall subnet: Hosts the Community Firewall endpoint
• 4 route tables: Management site visitors move via the firewall for each outbound requests and return site visitors

Visitors move

1. AgentCore Runtime executes the agent and invokes the AgentCore Browser instrument
2. AgentCore Browser initiates an HTTPS request from the non-public subnet
3. The non-public subnet route desk directs site 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 site visitors to the Web Gateway
7. The Web Gateway routes accredited site visitors to the exterior vacation spot
8. Return site visitors follows the symmetric path again via the firewall to the agent

This structure helps ensure that the browser site visitors is inspected and filtered, whatever the vacation spot.

Be aware: SNI-based filtering helps management which domains brokers hook up with on the TLS layer. For DNS-level management, together with controls to assist forestall 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 may doubtlessly resolve a blocked area via DNS and join by IP deal with straight.

Conditions

Earlier than you start, just be sure you have:

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

Walkthrough

For the entire 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 assets utilizing the CloudFormation template

Launch the CloudFormation template from the repository. You may maintain the stack default values. Nevertheless, make sure that so as to add a stack identify (for instance, “agentcore-egress“) to the “Stack identify” subject, select an Availability Zone on the “Availability Zone” menu, and embrace a legitimate current bucket identify on the “BucketConfigForOutput” parameter. Watch for the stack creation to finish, which generally takes 10 minutes. Proceed with the next steps after the stack standing adjustments 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 together with your accredited domains. Be aware 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

Vital: 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 the event you want a pip package deal set up. Most typical packages are pre-installed, making these domains optionally available in your use case.

Step 4: Configure the firewall coverage

The firewall coverage should use aws:drop_established because the default motion. This enables 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 site 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

# Permit all outbound site 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 (Elective)

You can even 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. If you happen to want pip to put in packages, make sure that .pypi.org and .pythonhosted.org are in your allowlist.

Step 6c: Deploy agent on AgentCore Runtime (Elective)

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: Check 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 instrument 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(methodology="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 ({sort(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()

    # Check 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)

    # Check 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 trip after the TCP handshake or return connection errors.

Be aware: Some allowed domains like docs.aws.amazon.com rely on CDN assets from domains similar to awsstatic.com and cloudfront.internet. If pages on allowed domains fail to render totally, add the required CDN domains to your allowlist.

You can even verify the firewall logs in CloudWatch for blocked connection makes an attempt:

# View latest 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 reveals IN_SYNC (rule adjustments 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. If you happen to obtain HTTP 403 errors on allowed domains, that is sometimes bot detection by the vacation spot web site, not a firewall block. Verify CloudWatch ALERT logs to verify—blocked connections could have express alert entries.

Finest 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 via the web.
• Configure the IGW ingress route desk: That is important for symmetric routing. With out it, return site visitors bypasses the firewall.
• Allow each ALERT and FLOW logs: ALERT logs seize blocked connections; FLOW logs present connection metadata for the site visitors.
• Watch for firewall sync: Rule adjustments 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 site visitors originating from the deployment VPC’s Classless Inter-Area Routing (CIDR) vary. If you happen to use a centralized firewall with AWS Transit Gateway to examine site visitors from a number of VPCs, you should configure the HOME_NET variable in your rule group to incorporate the supply CIDR ranges. With out this, site visitors from different VPCs can bypass area filtering.

Limitations and price issues

• Content material inspection requires TLS inspection: By default, area filtering operates on unencrypted TLS metadata (SNI headers) and might’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, site visitors may bypass area filtering. For prime-security deployments, mix area guidelines with IP-based guidelines for important blocked locations, or add DNS filtering as an extra layer. Moreover, think about pairing SNI-based guidelines with Route 53 DNS Firewall to assist forestall brokers from resolving blocked domains via DNS and connecting by IP deal with straight.
• HOME_NET scope in multi-VPC deployments: By default, Community Firewall area inspection solely applies to site visitors originating from the deployment VPC’s CIDR vary. If you happen to use a centralized firewall with AWS Transit Gateway (a number of VPCs routing via a shared firewall), you should configure the HOME_NET variable in your rule group to incorporate the supply CIDR ranges. With out this, site visitors from spoke VPCs bypasses area inspection. See Stateful area checklist rule teams for particulars.
• Prices will differ based mostly in your utilization. See NAT Gateway pricing and Community Firewall pricing for present charges.

Clear up

Delete assets on this order to keep away from ongoing prices:

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

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

Associated assets

For extra info, see the next assets.

Going additional

Area filtering via SNI inspection is one layer of egress safety. Relying in your necessities, think about these further mitigations:

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

Conclusion

By combining Amazon Bedrock AgentCore instruments with AWS Community Firewall, you can provide AI brokers managed internet entry whereas sustaining safety and compliance alignment. The domain-based filtering strategy 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 considerations raised by enterprise prospects:

• FSI compliance: Offers the community isolation and audit logging required for CISO-level safety opinions.
• Multi-tenant management: Allows 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 strategy to sustaining strict management over the place that entry leads. Fairly than sustaining customized squid proxies or advanced community infrastructure, you should use AWS managed companies 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