View a markdown version of this page

Security best practices for AWS Security Agent - AWS Security Agent
Use non-production environments for penetration testingValidate AI-generated security findingsReview and test generated remediation codeCode repository accessAccessible URLsCross Region Inference

Security best practices for AWS Security Agent

AWS Security Agent provides a number of security features to consider as you develop and implement your own security policies. The following best practices are general guidelines and don’t represent a complete security solution. Because these best practices might not be appropriate or sufficient for your environment, treat them as helpful considerations rather than prescriptions.

Use non-production environments for penetration testing

AWS Security Agent uses a comprehensive suite of penetration testing tools from the Kali Linux distribution. These tools are designed to identify security vulnerabilities and may perform actions that modify application state, data, or system configurations.

Best practice: Conduct penetration tests against non-production environments that mirror your production setup. These test environments should:

  • Not contain live customer data or sensitive production information

  • Be isolated from production systems

  • Have similar configurations and security controls as production

  • Not use credentials with access to production systems

Testing in production environments may result in:

  • Data modification or deletion

  • Service disruptions or performance degradation

  • Unintended state changes

  • Triggering of security alerts or incident response procedures

Validate AI-generated security findings

AWS Security Agent performs security analysis using AI agents. Due to the non-deterministic nature of AI systems, penetration test runs may produce varying results across different executions.

Best practice: Validate security findings before taking remediation action:

  • Review the verification scripts generated by AWS Security Agent for each finding

  • Execute verification scripts in your test environment to confirm the vulnerability

  • Consider running multiple penetration tests to ensure comprehensive coverage

  • Apply professional security judgment to assess finding severity and exploitability

Not all identified issues may represent exploitable vulnerabilities in your specific deployment context.

Review and test generated remediation code

AWS Security Agent can generate code fixes and security improvements for identified vulnerabilities. These AI-generated fixes require verification before deployment.

Best practice: Review all generated code changes:

  • Examine proposed fixes for completeness and correctness

  • Test fixes thoroughly in non-production environments

  • Verify that fixes don’t introduce new vulnerabilities or break functionality

  • Use AWS Security Agent to retest after applying fixes, or run the provided verification scripts

  • Follow your organization’s code review and approval processes

Code repository access

AWS Security Agent can provide security guidance on code changes through pull request comments and code review integration. To protect sensitive security information, this functionality operates under specific constraints.

Limitation: Code security guidance is restricted to private repositories only. This ensures that:

  • Security findings remain confidential to your organization

  • Potential vulnerabilities are not publicly disclosed before remediation

  • Generated fix recommendations don’t expose exploitation details

AWS Security Agent does not provide code security guidance for public repositories. It will not comment on public repositories or open-source projects where security findings would be publicly visible.

AWS Security Agent penetration tests can review and remediate private and public repositories that you configured for the pentest. If the repository is public, the remediation code will be provided as a downloadable diff file instead of a pull request.

Accessible URLs

Accessible URLs specify additional endpoints that the penetration testing environment can access during testing. These are necessary when your application depends on external services such as third-party authentication providers or CDNs. All network dependencies required for testing must be specified as either target URLs or accessible URLs. The network blocks access to any unspecified endpoints.

Security implications: AWS Security Agent is not instructed to perform security testing on accessible URLs. By specifying accessible URLs, you indicate trust in these dependencies. Penetration test data, including credentials, may be transmitted to these accessible URL endpoints during testing.

Cross Region Inference

AWS Security Agent automatically selects the optimal Region to process your inference requests. This maximizes available compute resources, model availability, and delivers the best customer experience. Your data remains stored only in the Region where the request originated; however, input prompts and output results might be processed outside that Region. We transmit all data encrypted across the AWS network.

AWS Security Agent uses two types of cross-region inference depending on the Region:

  • Geographic cross-region inference – Keeps data processing within specific geographic boundaries (such as US, EU, Australia, or Japan) for most features. For Code Remediation, requests from Australia and Japan are processed in the European Union. Used in US East (N. Virginia) – us-east-1, US West (Oregon) – us-west-2, Asia Pacific (Sydney) – ap-southeast-2, Asia Pacific (Tokyo) – ap-northeast-1, Europe (Frankfurt) – eu-central-1, and Europe (Ireland) – eu-west-1.

  • Global cross-region inference – Routes inference requests to any commercial AWS Region, optimizing available resources and enabling higher model throughput. Used in Asia Pacific (Mumbai) – ap-south-1, Asia Pacific (Singapore) – ap-southeast-1, and South America (São Paulo) – sa-east-1.

For Regions using global cross-region inference, input prompts and output results might be processed in any commercial AWS Region. All data transmitted during cross-region operations remains on the AWS network and does not traverse the public internet. We encrypt data in transit between AWS Regions.

The following table describes where your inference requests are processed based on the Region where the request originated and the feature used.

Request origin All features except Code Remediation Code Remediation

United States — US East (N. Virginia) – us-east-1, US West (Oregon) – us-west-2

United States

United States

European Union — Europe (Ireland) – eu-west-1, Europe (Frankfurt) – eu-central-1

European Union

European Union

Australia — Asia Pacific (Sydney) – ap-southeast-2

Australia

European Union

Japan — Asia Pacific (Tokyo) – ap-northeast-1

Japan

European Union

South America — South America (São Paulo) – sa-east-1

Any commercial AWS Region

Any commercial AWS Region

India — Asia Pacific (Mumbai) – ap-south-1

Any commercial AWS Region

Any commercial AWS Region

Southeast Asia — Asia Pacific (Singapore) – ap-southeast-1

Any commercial AWS Region

Any commercial AWS Region

Cross-Region inference is always enabled and cannot be opted out of. Cross-Region inference is not impacted by customer policies in Service Control Policies (SCPs) or AWS Control Tower that restrict customer content to specific Regions. For more information about how AWS Security Agent protects your data during cross-Region processing, see Cross-Region data processing.