Security best practices for AWS Security Agent - AWS Security Agent

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 will automatically select the optimal region within your geography to process your inference requests. This maximizes available compute resources, model availability, and delivers the best customer experience. Your data will remain stored only in the region where the request originated, however, input prompts and output results may be processed outside that region. All data will be transmitted encrypted across Amazon’s secure network.

AWS Security Agent will securely route your inference requests to available compute resources within the geographic area where the request originated, as follows:

  • Inference requests originating in the European Union will be processed within the European Union.

  • Inference requests originating in the United States will be processed within the United States.

  • Inference requests originating in Australia will be processed within Australia.

  • Inference requests originating within Japan will be processed within Japan.

Cross-Region inference is always enabled and cannot be opted out of.

  • Data residency – All data processing occurs within your geographic area. If your organization requires data processing within a specific single region, evaluate whether processing across the broader geographic boundary satisfies your compliance obligations.

  • IAM and Service Control Policies – Ensure your IAM policies and Service Control Policies (SCPs) allow access to regions within your geography used for cross-Region inference operations.