Management which domains your AI brokers can entry

AI brokers that may browse the online open highly effective potentialities—from analysis automation to real-time knowledge 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 knowledge 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’ll be able to management software 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 submit, we present you how you can configure AWS Community Firewall to limit AgentCore assets to an allowlist of authorised web domains. You need to 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 submit 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 submit. For inbound entry management (limiting who can invoke your brokers), you may also see Useful resource-based insurance policies for Amazon Bedrock AgentCore. These assist 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 evaluations for AI agent deployments persistently 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 personal, and that further safety controls like net 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. Frequent 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 by 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 immediate injection assaults. Customized URL allowlists cut back the assault floor by limiting the browser to authorised 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.

Answer overview

The answer deploys AgentCore Browser in a non-public subnet with no direct web entry. The outbound visitors routes by AWS Community Firewall, which inspects TLS Server Identify Indication (SNI) headers to find out the vacation spot area and apply filtering guidelines. It’s also possible to monitor Community Firewall actions taken to limit visitors by 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 visitors circulate by the firewall for each outbound requests and return visitors

Visitors circulate

1. AgentCore Runtime executes the agent and invokes the AgentCore Browser software
2. AgentCore Browser initiates an HTTPS request from the personal subnet
3. The personal subnet route desk directs visitors to the NAT Gateway within the public subnet
4. The NAT Gateway interprets the personal IP deal with and forwards the request to the Community Firewall endpoint
5. Community Firewall inspects the TLS SNI header to establish 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 authorised visitors to the exterior vacation spot
8. Return visitors follows the symmetric path again by the firewall to the agent

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

Notice: SNI-based filtering helps management which domains brokers connect 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 might doubtlessly resolve a blocked area by DNS and join by IP deal with straight.

Stipulations

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
• Fundamental 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’ll be able to hold the stack default values. Nevertheless, make sure that so as to add a stack title (for instance, “agentcore-egress“) to the “Stack title” area, select an Availability Zone on the “Availability Zone” menu, and embrace a sound present bucket title on the “BucketConfigForOutput” parameter. Await the stack creation to finish, which usually takes 10 minutes. Proceed with the next steps after the stack standing modifications to CREATE_COMPLETE.

Step 2: Evaluate the IAM execution function

AgentCore Browser requires an IAM function 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 authorised domains. Notice 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

Necessary: Embody .amazonaws.com in your allowlist if the browser requires AWS service entry or use VPC Endpoints as a substitute.

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 operate URLs. For tighter management, use VPC Endpoints for AWS service entry and allowlist solely the particular exterior domains your brokers want.

For Code Interpreter: Contemplate including “.pypi.org” and “.pythonhosted.org” when you want a pip bundle set up. Commonest packages are pre-installed, making these domains non-obligatory to 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 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 personal subnet:

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

Step 6b: Create AgentCore Code Interpreter (Optionally available)

It’s also possible to 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. When you 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 (Optionally available)

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:function/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 software 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.change("wss://", "https://"))
SigV4Auth(credentials, "bedrock-agentcore", REGION).add_auth(request)
headers = dict(request.headers)

def test_domain(web page, url, expected_success):
    attempt:
        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()

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

Notice: Some allowed domains like docs.aws.amazon.com rely on CDN assets from domains reminiscent of awsstatic.com and cloudfront.web. If pages on allowed domains fail to render absolutely, add the required CDN domains to your allowlist.

It’s also possible to 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 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. When you 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.

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 the web.
• Configure the IGW ingress route desk: That is important 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.
• Await 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. When you use a centralized firewall with AWS Transit Gateway to examine 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, visitors from different VPCs can bypass area filtering.

Limitations and value 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 threat: 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 important blocked locations, or add DNS filtering as a further layer. Moreover, contemplate pairing SNI-based guidelines with Route 53 DNS Firewall to assist forestall brokers from resolving blocked domains by 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. When you use a centralized firewall with AWS Transit Gateway (a number of VPCs routing by a shared firewall), you should 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 checklist rule teams for particulars.
• Prices will fluctuate 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 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

Notice: 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 by SNI inspection is one layer of egress safety. Relying in your necessities, contemplate 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 net 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: Supplies the community isolation and audit logging required for CISO-level safety evaluations.
• Multi-tenant management: Permits per-customer or per-execution area insurance policies for SaaS suppliers.
• Immediate injection protection: Restricts agent navigation to authorised domains, serving to cut back the assault floor for immediate injection.
• Audit proof: Generates CloudWatch logs that assist compliance audit necessities.

For enterprises deploying AI brokers that want web entry for analysis, knowledge gathering, or API integrations, this sample gives a production-ready method to sustaining strict management over the place that entry leads. Slightly 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.

Concerning the authors