# Security in AWS Security Agent Security Cloud security at AWS is the highest priority. As an AWS customer, you benefit from a data center and network architecture that is built to meet the requirements of the most security-sensitive organizations. Security is a shared responsibility between AWS and you. The [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) describes this as security *of* the cloud and security *in* the cloud: + **Security of the cloud** – AWS is responsible for protecting the infrastructure that runs AWS Security Agent in the AWS Cloud. This includes the service infrastructure, AI models, and penetration testing agents. Third-party auditors regularly test and verify the effectiveness of our security as part of the [AWS compliance programs](https://aws.amazon.com/compliance/programs/). + **Security in the cloud** – Your responsibility includes the following areas: + Managing access to AWS Security Agent through IAM policies and permissions + Protecting the content you provide to the service, including design documents, code repositories, and application URLs for penetration testing + Configuring which repositories and applications are monitored + Reviewing and acting on security findings provided by the service + Securing your applications based on the remediation guidance provided + The sensitivity of your data, your company’s requirements, and applicable laws and regulations This documentation helps you understand how to apply the shared responsibility model when using AWS Security Agent. # Security Considerations for AWS Security Agent and AI assisted penetration testing Security Considerations AWS Security Agent is a frontier agent that proactively secures your applications throughout the development lifecycle across all your environments. It conducts automated security reviews customized to your requirements, with security teams centrally defining standards that are automatically validated during reviews. Security Agent performs on-demand penetration testing customized to your application, discovering and reporting verified security risks. This approach scales security expertise across your applications to match development velocity while providing comprehensive security coverage. By integrating security from design to deployment, it helps prevent vulnerabilities early and at scale. Security teams define organizational security requirements once in the AWS Console: approved authorization libraries, logging standards, and data access policies. AWS Security Agent automatically enforces these security requirements throughout development, evaluating architectural documents and code against your standards and providing specific guidance when it detects violations. This delivers consistent security enforcement across teams and scales reviews to match development velocity. For deployment validation, AWS Security Agent transforms penetration testing from a periodic bottleneck into an on-demand capability. Security teams provide target URLs, authentication details, source code and documentation. AWS Security Agent develops deep application understanding and executes sophisticated attack chains to discover and validate vulnerabilities, enabling teams to test whenever needed. ## Key capabilities AWS Security Agent provides comprehensive security capabilities spanning the entire development lifecycle. ## Design security review AWS Security Agent provides on-demand security feedback on design documents and assesses compliance with organizational security requirements before code is written. Security teams upload design documents through the web application, where the agent analyzes them against your security requirements and surfaces findings with remediation guidance. This accelerates hours-long manual reviews into focused analysis, enabling teams to address security concerns when remediation is most efficient. ## Code security review AWS Security Agent analyzes pull requests or uploaded code for organizational security requirements and common security issues like missing input validation and SQL injection risks. The agent provides remediation guidance directly within your code repository platform. Security teams configure which repositories to monitor, scaling evaluation across all codebases while maintaining oversight on critical issues. ## On-demand penetration testing AWS Security Agent provides on-demand penetration testing that discovers and reports validated security vulnerabilities through tailored multi-step attack scenarios. AWS Security Agent deploys specialized AI agents that develop application context from provided documentation and credentials, then execute sophisticated attack chains to identify complex vulnerabilities that conventional tools miss. It documents findings with impact analysis, reproducible attack paths, and ready-to-implement code fixes, accelerating penetration testing from weeks to hours and scaling validation across your application portfolio. ## FAQs ### Security & Control #### How does AWS Security Agent authenticate and maintain access to systems? Penetration testing is the only capability in AWS Security Agent that can authenticate to a user’s system at runtime. The AWS Security Agent accepts credentials in the form of static username and password credentials (stored in Secrets Manager), or a credential vendor (as a Lambda Function) as configuration before starting the pen test. These credentials are used to exercise the normal functionality of the user’s system/application through the lifecycle of the pen test. We encourage users to create new credentials with appropriately scoped permissions for the purposes of pentesting. #### Can users control the scope and depth of testing to prevent unintended system impacts? AWS Security Agent allows customers to select a specific category of vulnerability to explore in an endpoint. Users can specify out-of-scope URLs to prevent AWS Security Agent from performing penetration testing against those targets. https://docs.aws.amazon.com/securityagent/latest/userguide/perform-penetration-test.html #### Can AWS Security Agent itself pose a security risk? AWS Security Agent is instructed to discover security risks, but to do so using intentionally minimal impacting payloads (like extracting the SQL version instead of dropping a table when a SQL injection attack is discovered). AWS Security Agent is also confined to deterministic guardrails to prevent risky behavior like creating excessive load against the target application. While guardrails are in place, there could still be unintentional or non-obvious business logic interactions, therefore, we always recommend doing penetration testing against a pre-production environment. #### What data does AWS Security Agent collect and where is it stored? AWS Security Agent allows users to upload artifacts to provide context about their application being tested. For more information on data protection, see [Data protection in AWS Security Agent](data-protection.md). 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. For more information, see [Cross Region Inference](https://docs.aws.amazon.com/securityagent/latest/userguide/security-best-practices.html#_cross_region_inference). #### What controls are present to block unauthorized testing against an endpoint? Endpoints that are specified as target URLs for pentesting will require DNS validation or HTTP validation as a measure of ownership. AWS Security Agent will ask the customer to add a TXT record to the endpoint’s DNS or expose an HTTP Route returning validation string as proof of ownership. Only after demonstrating proof of ownership will the user be able to proceed with a pentest. Requests to URLs outside of the target and accessible URLs will be blocked by the network. Customers are responsible for ensuring they have proper authorization to test all systems that may be affected by their penetration testing activities. All use of AWS Security Agent must comply with the AWS Acceptable Use Policy (https://aws.amazon.com/aup/). #### How do users block and report any abuse using AWS Security Agent? AWS Security Agent continuously monitors requests and attempts to access URLs that are outside of the target URLs. If abuse is detected, such as attempting to use AWS Security Agent to conduct unauthorized testing on a third party endpoint, any ongoing pentests in the account will be terminated. Customers can reach out to AWS Support or their AWS account team for help. #### Can AWS Security Agent replace pen testing workflow? AWS Security Agent is not a professional penetration testing service, and we encourage users to integrate AWS Security Agent into their security review workflow. AWS Security Agent can provide accessibility to penetration testing on-demand during the development phase of the software lifecycle when engaging with pentesting professionals would be too early, impractical, or need to be re-evaluated too frequently. Security professionals can review findings from AWS Security Agent to validate them, explain them, or extend upon them for new novel findings (if they exist). #### Can users set up role-based access control (RBAC) for different team members? Yes. AWS Security Agent integrates with AWS IAM Identity Center, allowing admins to manage team members who can access the AWS Security Agent web application which allows users to create, manage and view design reviews and pentests. ### Testing Capabilities #### What types of vulnerabilities can AWS Security Agent detect? AWS Security Agent detects vulnerabilities in the OWASP Top 10 for web applications. AWS Security Agent provides specific risk types that you can include or exclude in testing outlined below. Findings could arise within these risk categories or from novel findings discovered by following leads from a combination of these risk categories. + [Arbitrary File Upload](https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html) + Arbitrary File Upload confirms that the application should be able to fend off bogus and malicious files in a way to keep the application and the users safe + [Code Injection](https://owasp.org/www-community/attacks/Code_Injection) + Code Injection is the general term for attack types which consist of injecting code that is then interpreted/executed by the application + [Command Injection](https://owasp.org/www-community/attacks/Command_Injection) + Command injection is an attack in which the goal is execution of arbitrary commands on the host operating system via a vulnerable application + [Cross-Site Scripting](https://owasp.org/www-community/attacks/xss/) (XSS) + Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites + [Insecure Direct Object Reference](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/05-Authorization_Testing/04-Testing_for_Insecure_Direct_Object_References) + Insecure Direct Object References (IDOR) occur when an application provides direct access to objects based on user-supplied input + [JSON Web Token Vulnerabilities](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06-Session_Management_Testing/10-Testing_JSON_Web_Tokens) + JWTs are a common source of vulnerabilities, both in how they are implemented in applications, and in the underlying libraries + [Local File Inclusion](https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/07-Input_Validation_Testing/11.1-Testing_for_Local_File_Inclusion) + File Inclusion vulnerability allows an attacker to include a file, usually exploiting a “dynamic file inclusion” mechanisms implemented in the target application + [Path Traversal](https://owasp.org/www-community/attacks/Path_Traversal) + Path Traversal attack (also known as directory traversal) aims to access files and directories that are stored outside the web root folder + [Privilege Escalation](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/05-Authorization_Testing/03-Testing_for_Privilege_Escalation) + Privilege escalation occurs when a user gets access to more resources or functionality than they are normally allowed, and such elevation or changes should have been prevented by the application + [Server-Side Request Forgery](https://owasp.org/www-community/attacks/Server_Side_Request_Forgery) (SSRF) + Server-Side Request Forgery (SSRF) occurs when the attacker can abuse functionality on the server to read or update internal resources + [Server-Side Template Injection](https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/07-Input_Validation_Testing/18-Testing_for_Server_Side_Template_Injection) + Server Side Template Injection vulnerabilities (SSTI) occur when user input is embedded in a template in an unsafe manner and results in remote code execution on the server + [SQL Injection](https://owasp.org/www-community/attacks/SQL_Injection) + SQL injection attack consists of insertion or “injection” of a SQL query via the input data from the client to the application + [XML External Entity](https://owasp.org/www-community/vulnerabilities/XML_External_Entity_(XXE)_Processing) + XML External Entity attack is a type of attack against an application that parses XML input. This attack occurs when XML input containing a reference to an external entity is processed by a weakly configured XML parser #### What authentication methods does AWS Security Agent support? AWS Security Agent supports common authentication methods, including OAuth and JWT. For more information, see the [documentation](https://docs.aws.amazon.com/securityagent/latest/userguide/provide-testing-credentials.html). #### How does AWS Security Agent handle rate limiting and Denial of Service (DOS) prevention? AWS Security Agent has guardrails to prevent it from disrupting or taking down endpoints under test, including DOS. It has internal velocity controls to detect and handle unexpected traffic patterns. #### Can AWS Security Agent test both REST and GraphQL APIs? Yes, AWS Security Agent can test API endpoints. We encourage customers to provide API documentation as **Additional Learning Resources** allowing AWS Security Agent to have better context on the shape and functionality of each API being tested. #### How can users verify that AWS Security Agent has covered all critical application logic and endpoints? AWS Security Agent will do a breadth-first exploration of the target application(s) and attempt to exercise it normally before attempting any exploits. This allows it to build a working understanding of the application at runtime and discover critical application logic and endpoints. Given its stochastic nature, AWS Security Agent is not guaranteed to discover and test all critical applications and endpoints for any target application. The AWS Security Agent web application provides visibility into all discovered endpoints and actions taken in the Penetration test logs. ### Accuracy & Reliability #### How does AWS Security Agent validate findings before reporting? AWS Security Agent uses deterministic validators to help validate the reported finding. In the risk types where it is not possible to use deterministic validators, AWS Security Agent will independently replay the finding steps to gain confidence in the validity of the finding. AWS Security Agent only reports the high or medium confidence findings and hides the unverified findings by default. #### Can AWS Security Agent adapt to custom application logic? AWS Security Agent optionally accepts source code, threat model, design documents, and API documentation as **Additional Learning Resources** to gain user-directed context on the target application used in the lifecycle of a pentest. #### Can users review AWS Security Agent testing methodology before execution? Currently there is no way to preview AWS Security Agent’s course of action. The AWS Security Agent plan is dynamic in nature based on its exploration of the target application. Customers can monitor AWS Security Agent as it goes through its exploration in real time by observing the penetration test logs. If logs show an invalid or undesirable trajectory, customers can stop ongoing pentest run. ### Integration & Deployment #### Does AWS Security Agent integrate with security tools (SIEM, vulnerability management) or CI/CD pipelines? AWS Security Agent does not integrate with any existing security tools or CI/CD pipelines. #### How does AWS Security Agent handle environment-specific configurations? AWS Security Agent can be configured to run with specific IAM roles, inside VPCs, with customer-specified application relevant credentials, and with Github source repositories as source code reference to the target application. #### Can AWS Security Agent run in air-gapped or isolated environments? [AWS Security Agent can be configured to have connectivity to VPCs](connect-agent-vpc.md), including ones that do not have outbound internet access. #### Can multiple team members run tests simultaneously? AWS Security Agent supports 5 concurrent pentest runs per account, independent of who starts the test. Customers can create a maximum of 100 Agent Spaces and 1,000 Pentest projects. ### Operational Impact #### What’s the performance impact on tested systems? AWS Security Agent has guardrails to prevent it from disrupting or taking down endpoints under test. This includes velocity controls on number of calls that AWS Security Agent can make to an endpoint. System or the endpoint under test should expect some increase in traffic and potential monitoring alerts being triggered due to the pen test activity. Our recommendation is to only run AWS Security Agent or any pen testing activity in pre-production environment. #### Can users schedule or throttle AWS Security Agent? AWS Security Agent does not have public APIs or the ability to schedule the pen test runs. AWS Security Agent also does not offer a concurrency control on requests to the target endpoint when starting the pen test run. If AWS Security Agent is causing problems for target endpoints, customers can stop the ongoing pentest(s). #### What’s the typical duration for a complete security assessment? The runtime for each pentest depends on the breadth of the target application, and the risk types configured to be assessed. Typical pentest runs can take 12 hours long on configurations that include all risk types. # AWS managed policies for AWS Security Agents AWS managed policies An AWS managed policy is a standalone policy that is created and administered by AWS. AWS managed policies are designed to provide permissions for many common use cases so that you can start assigning permissions to users, groups, and roles. Keep in mind that AWS managed policies might not grant least-privilege permissions for your specific use cases because they’re available for all AWS customers to use. We recommend that you reduce permissions further by defining [customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) that are specific to your use cases. You cannot change the permissions defined in AWS managed policies. If AWS updates the permissions defined in an AWS managed policy, the update affects all principal identities (users, groups, and roles) that the policy is attached to. AWS is most likely to update an AWS managed policy when a new AWS service is launched or new API operations become available for existing services. For more information, see [AWS managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) in the *IAM User Guide*. ## AWS managed policy: SecurityAgentWebAppAPIPolicy Grants permissions to interact with the Security Agent Web Application API. This policy enables users to configure and execute automated security penetration tests, manage test executions, view security findings, and access Security Agent resources. This policy references the legacy Agent Instance resource type and specific legacy IAM actions. **Permissions details** This policy grants permissions to interact with the Security Testing Control service (securityagent:\$1) for: + Pentest Management: Create, update, delete, and list penetration tests and their execution jobs + Security Findings: View, describe, and update security findings from completed tests, including related content and metadata. + Task Management: List and retrieve code review and documentation review tasks + Resource Discovery: List and view agent instances, artifacts, integrations, and discovered endpoints + Test Execution: Start and stop pentest executions with real-time monitoring capabilities + Code Remediation: Start automated code remediation for security findings To view the latest version of the JSON policy document, see [SecurityAgentWebAppAPIPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/SecurityAgentWebAppAPIPolicy.html) in the AWS Managed Policy Reference Guide. ## AWS managed policy: AWSSecurityAgentWebAppPolicy Grants permissions to interact with the Security Agent Web Application API. This policy enables users to configure and execute automated security penetration tests, manage test executions, view security findings, and access Security Agent resources. **Permissions details** This policy grants permissions to interact with the Security Testing Control service (securityagent:\$1) for: + Pentest Management: Create, update, delete, and list penetration tests and their jobs + Security Findings: View, describe, and update security findings from completed tests, including related content and metadata. + Task Management: List and retrieve code review and design review tasks + Resource Discovery: List and view agent spaces, artifacts, integrations, and discovered endpoints + Test Execution: Start and stop pentest jobs with real-time monitoring capabilities + Code Remediation: Start automated code remediation for security findings To view the latest version of the JSON policy document, see [AWSSecurityAgentWebAppPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSSecurityAgentWebAppPolicy.html) in the AWS Managed Policy Reference Guide. ## AWS Security Agents updates to AWS managed policies View details about updates to AWS managed policies for AWS Security Agents since this service began tracking these changes. To receive notifications of all source file changes to this specific documentation page, you can subscribe to the following URL with an RSS reader: | Change | Description | Date | | --- | --- | --- | | Added permissions to [AWSSecurityAgentWebAppPolicy](#security-iam-awsmanpol-AWSSecurityAgentWebAppPolicy). | Added `TargetDomain` and `DesignReviewFeedback` resource permissions for the new resource types. | March 31, 2026 | | Added a new managed policy [AWSSecurityAgentWebAppPolicy](#security-iam-awsmanpol-AWSSecurityAgentWebAppPolicy). | Added managed policy `AWSSecurityAgentWebAppPolicy` for the new AgentSpace resource type and IAM action name changes. | February 9, 2026 | | Added permissions to [SecurityAgentWebAppAPIPolicy](#security-iam-awsmanpol-SecurityAgentWebAppAPIPolicy). | Added `securityagent:StartCodeRemediation` to allow users to start automated code remediation for security findings. | January 20, 2026 | | Added permissions to [SecurityAgentWebAppAPIPolicy](#security-iam-awsmanpol-SecurityAgentWebAppAPIPolicy). | Added `securityagent:BatchGetSecurityTestContentMetadata` to allow users to view images in the console. | December 5, 2025 | | AWS Security Agents started tracking changes. | AWS Security Agents started tracking changes for its AWS managed policies. | December 2, 2025 | # Data protection in AWS Security Agent Data protection The AWS [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) applies to data protection in AWS Security Agent. As described in this model, AWS is responsible for protecting the global infrastructure that runs all of the AWS Cloud. You are responsible for maintaining control over your content that is hosted on this infrastructure. You are also responsible for the security configuration and management tasks for the AWS services that you use. For information about data protection in Europe, see the [AWS Shared Responsibility Model and GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) blog post on the *AWS Security Blog*. For data protection purposes, we recommend that you protect AWS account credentials and set up individual users with AWS IAM Identity Center or AWS Identity and Access Management (IAM). That way, each user is given only the permissions necessary to fulfill their job duties. We also recommend that you secure your data in the following ways: + Use multi-factor authentication (MFA) with each account. + Use SSL/TLS to communicate with AWS resources. We require TLS 1.2 and recommend TLS 1.3. + Set up API and user activity logging with AWS CloudTrail. For information about using CloudTrail trails to capture AWS activities, see [Working with CloudTrail trails](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-working-with-trails.html) in the *AWS CloudTrail User Guide*. + Use AWS encryption solutions, along with all default security controls within AWS services. + Use advanced managed security services such as Amazon Macie, which assists in discovering and securing sensitive data that is stored in Amazon S3. + If you require FIPS 140-3 validated cryptographic modules when accessing AWS through a command line interface or an API, use a FIPS endpoint. For more information about the available FIPS endpoints, see [Federal Information Processing Standard (FIPS) 140-3](https://aws.amazon.com/compliance/fips/). We strongly recommend that you never put confidential or sensitive information, such as your customers' email addresses, into tags or free-form text fields such as a **Name** field. This includes when you work with AWS Security Agent or other AWS services using the console, API, AWS CLI, or AWS SDKs. Any data that you enter into tags or free-form text fields used for names may be used for billing or diagnostic logs. If you provide a URL to an external server, we strongly recommend that you do not include credentials information in the URL to validate your request to that server. ## Encryption at rest AWS Security Agent encrypts all data at rest using AWS-managed encryption keys by default. This includes: + **Design documents and code** – All design documents, code repositories, and application artifacts you provide for security reviews are encrypted using AES-256 encryption. + **Security findings** – All security findings, vulnerability reports, and remediation recommendations are encrypted at rest. + **Configuration data** – Security requirements, custom policies, and service configurations are encrypted. + **Audit logs** – All service activity logs and audit trails are encrypted. AWS Security Agent uses AWS Key Management Service (AWS KMS) to manage encryption keys. You can optionally use a customer managed key to encrypt your data, giving you full control over the encryption keys that protect your resources. For more information, see [Customer managed keys for AWS Security Agent](customer-managed-keys.md). ## Encryption in transit AWS Security Agent encrypts all data in transit using Transport Layer Security (TLS) 1.2 or higher. This applies to: + **API communications** – All API calls between your applications and AWS Security Agent use HTTPS with TLS encryption. + **Console access** – The AWS Security Agent console is accessed over HTTPS. + **Repository connections** – Connections to GitHub and other code repositories use encrypted protocols. + **Agent communications** – All communications between the AWS Security Agent service and penetration testing agents use encrypted channels. ## Key management AWS Security Agent uses AWS Key Management Service (AWS KMS) to manage encryption keys. By default, data is encrypted using AWS-managed keys. You can optionally specify a customer managed key when creating resources such as Agent Spaces and integrations. For more information, see [Customer managed keys for AWS Security Agent](customer-managed-keys.md). ## Internetwork traffic privacy AWS Security Agent uses the public internet to communicate with GitHub. In the default configuration, AWS Security Agent uses the public internet to reach your app for penetration testing. You can optionally configure penetration tests to use a VPC to access your application. For more information, see [Connect agent to private VPC resources](connect-agent-vpc.md). ## Data deletion When you delete data from AWS Security Agent: + The data is marked for deletion and is no longer accessible through the service. + The data is deleted from all AWS Security Agent systems within 30 days. To delete your data 1. In the AWS console, navigate to AWS Security Agent. 1. Choose the data you want to delete (security reviews, findings, or custom requirements). 1. Choose **Delete** and confirm the deletion. # Identity and access management for AWS Security Agent Identity and access management AWS Identity and Access Management (IAM) is an AWS service that helps an administrator securely control access to AWS resources. IAM administrators control who can be *authenticated* (signed in) and *authorized* (have permissions) to use AWS Security Agent resources. IAM is an AWS service that you can use with no additional charge. ## Audience How you use AWS Identity and Access Management (IAM) differs, depending on the work you do in AWS Security Agent. **Service user** – If you use the AWS Security Agent service to do your job, then your administrator provides you with the credentials and permissions that you need. As you use more AWS Security Agent features to do your work, you might need additional permissions. Understanding how access is managed can help you request the right permissions from your administrator. If you cannot access a feature in AWS Security Agent, see [Troubleshooting AWS Security Agent identity and access](security-iam-troubleshoot.md). **Service administrator** - If you’re in charge of AWS Security Agent resources at your company, you probably have full access to AWS Security Agent. It’s your job to determine which AWS Security Agent features and resources your service users should access. You must then submit requests to your IAM administrator to change the permissions of your service users. Review the information on this page to understand the basic concepts of IAM. To learn more about how your company can use IAM with AWS Security Agent, see [How AWS Security Agent works with IAM](security_iam_service-with-iam.md). ** IAM administrator** - If you’re an IAM administrator, you might want to learn details about how you can write policies to manage access to AWS Security Agent. To view example AWS Security Agent identity-based policies that you can use in IAM, see [AWS Security Agent identity-based policy examples](security-iam-id-based-policy-examples.md). ## Authenticating with identities Authentication is how you sign in to AWS using your identity credentials. You must be *authenticated* (signed in to AWS) as the AWS account root user, an IAM user, or by assuming an IAM role. AWS suggests using an IAM role, and avoiding using the root user directly. You can sign in to AWS as a federated identity by using credentials provided through an identity source. AWS IAM Identity Center (IAM Identity Center) users, your company’s single sign-on authentication, and your Google or Facebook credentials are examples of federated identities. When you sign in as a federated identity, your administrator previously set up identity federation using IAM roles. When you access AWS by using federation, you are indirectly assuming a role. Depending on the type of user you are, you can sign in to the AWS Management Console or the AWS access portal. For more information about signing in to AWS, see [How to sign in to your AWS Account](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) in the *AWS Sign-In User Guide*. If you access AWS programmatically, AWS provides a software development kit (SDK) and a command line interface (CLI) to cryptographically sign your requests using your credentials. If you don’t use AWS tools, you must sign requests yourself. For more information about using the recommended method to sign requests yourself, see [Signature Version 4 signing process](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html) in the *AWS General Reference*. Regardless of the authentication method that you use, you might also be required to provide additional security information. For example, AWS recommends that you use multi-factor authentication (MFA) to increase the security of your account. To learn more, see [Multi-factor authentication](https://docs.aws.amazon.com/singlesignon/latest/userguide/enable-mfa.html) in the *AWS IAM Identity Center (successor to AWS Single Sign-On) User Guide* and [Using multi-factor authentication (MFA) in AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html) in the *IAM User Guide*. ### AWS account root user When you first create an AWS account, you begin with a single sign-in identity that has complete access to all AWS services and resources in the account. This identity is called the AWS account root user and is accessed by signing in with the email address and password that you used to create the account. We strongly recommend that you don’t use the root user for your everyday tasks. Safeguard your root user credentials and use them to perform tasks that only the root user can perform. For the complete list of tasks that require you to sign in as the root user, see [Tasks that require root user credentials](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html) in the *Account Management Reference Guide*. ### Federated identity As a best practice, require human users, including users that require administrator access, to use federation with an identity provider to access AWS services by using temporary credentials. A federated identity is a user from your enterprise user directory, a web identity provider, the AWS Directory Service, the Identity Center directory, or any user that accesses AWS services by using credentials provided through an identity source. When federated identities access AWS accounts, they assume roles, and the roles provide temporary credentials. For centralized access management, we recommend that you use AWS IAM Identity Center. You can create users and groups in IAM Identity Center, or you can connect and synchronize to a set of users and groups in your own identity source for use across all your AWS accounts and applications. For information about IAM Identity Center, see [What is IAM Identity Center?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) in the *AWS IAM Identity Center (successor to AWS Single Sign-On) User Guide*. ### IAM users and groups An * [IAM user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) * is an identity within your AWS account that has specific permissions for a single person or application. Where possible, we recommend relying on temporary credentials instead of creating IAM users who have long-term credentials such as passwords and access keys. However, if you have specific use cases that require long-term credentials with IAM users, we recommend that you rotate access keys. For more information, see [Rotate access keys regularly for use cases that require long-term credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#rotate-credentials) in the *IAM User Guide*. An [IAM group](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) is an identity that specifies a collection of IAM users. You can’t sign in as a group. You can use groups to specify permissions for multiple users at a time. Groups make permissions easier to manage for large sets of users. For example, you could have a group named *IAMAdmins* and give that group permissions to administer IAM resources. Users are different from roles. A user is uniquely associated with one person or application, but a role is intended to be assumable by anyone who needs it. Users have permanent long-term credentials, but roles provide temporary credentials. To learn more, see [When to create an IAM user (instead of a role)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose) in the *IAM User Guide*. ### IAM roles An * [IAM role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) * is an identity within your AWS account that has specific permissions. It is similar to an IAM user, but is not associated with a specific person. You can temporarily assume an IAM role in the AWS Management Console by [switching roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html). You can assume a role by calling an AWS CLI or AWS API operation or by using a custom URL. For more information about methods for using roles, see [Using IAM roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use.html) in the *IAM User Guide*. IAM roles with temporary credentials are useful in the following situations: + **Federated user access** – To assign permissions to a federated identity, you create a role and define permissions for the role. When a federated identity authenticates, the identity is associated with the role and is granted the permissions that are defined by the role. For information about roles for federation, see [Creating a role for a third-party Identity Provider](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp.html) in the *IAM User Guide*. If you use IAM Identity Center, you configure a permission set. To control what your identities can access after they authenticate, IAM Identity Center correlates the permission set to a role in IAM. For information about permissions sets, see [Permission sets](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html) in the *AWS IAM Identity Center (successor to AWS Single Sign-On) User Guide*. + **Temporary IAM user permissions** – An IAM user can assume an IAM role to temporarily take on different permissions for a specific task. + **Cross-account access** – You can use an IAM role to allow someone (a trusted principal) in a different account to access resources in your account. Roles are the primary way to grant cross-account access. However, with some AWS services, you can attach a policy directly to a resource (instead of using a role as a proxy). To learn the difference between roles and resource-based policies for cross-account access, see [How IAM roles differ from resource-based policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_compare-resource-policies.html) in the *IAM User Guide*. + **Cross-service access** – Some AWS services use features in other AWS services. For example, when you make a call in a service, it’s common for that service to run applications in Amazon EC2 or store objects in Amazon S3. A service might do this using the calling principal’s permissions, using a service role, or using a service-linked role. + **Principal permissions** – When you use an IAM user or role to perform actions in AWS, you are considered a principal. Policies grant permissions to a principal. When you use some services, you might perform an action that then triggers another action in a different service. In this case, you must have permissions to perform both actions. + **Service role** – A service role is an IAM role that a service assumes to perform actions on your behalf. An IAM administrator can create, modify, and delete a service role from within IAM. For more information, see [Creating a role to delegate permissions to an AWS service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) in the *IAM User Guide*. + **Service-linked role** – A service-linked role is a type of service role that is linked to an AWS service. The service can assume the role to perform an action on your behalf. Service-linked roles appear in your AWS account and are owned by the service. An IAM administrator can view, but not edit the permissions for service-linked roles. + **Applications running on Amazon EC2 ** – You can use an IAM role to manage temporary credentials for applications that are running on an Amazon EC2 instance and making AWS CLI or AWS API requests. This is preferable to storing access keys within the Amazon EC2 instance. To assign an AWS role to an Amazon EC2 instance and make it available to all of its applications, you create an instance profile that is attached to the instance. An instance profile contains the role and enables programs that are running on the Amazon EC2 instance to get temporary credentials. For more information, see [Using an IAM role to grant permissions to applications running on Amazon EC2 instances](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html) in the *IAM User Guide*. To learn whether to use IAM roles, see [When to create an IAM role (instead of a user)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose_role) in the *IAM User Guide*. ## Managing access using policies You control access in AWS by creating policies and attaching them to AWS identities or resources. A policy is an object in AWS that, when associated with an identity or resource, defines their permissions. AWS evaluates these policies when a principal (user, root user, or role session) makes a request. Permissions in the policies determine whether the request is allowed or denied. Most policies are stored in AWS as JSON documents. For more information about the structure and contents of JSON policy documents, see [Overview of JSON policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) in the *IAM User Guide*. Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**. Every IAM entity (user or role) starts with no permissions. By default, users can do nothing, not even change their own password. To give a user permission to do something, an administrator must attach a permissions policy to a user. Or the administrator can add the user to a group that has the intended permissions. When an administrator gives permissions to a group, all users in that group are granted those permissions. IAM policies define permissions for an action regardless of the method that you use to perform the operation. For example, suppose that you have a policy that allows the `iam:GetRole` action. A user with that policy can get role information from the AWS Management Console, the AWS CLI, or the AWS API. ### Identity-based policies Identity-based policies are JSON permissions policy documents that you can attach to an identity, such as an IAM user, role, or group. These policies control what actions users and roles can perform, on which resources, and under what conditions. To learn how to create an identity-based policy, see [Creating IAM policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) in the *IAM User Guide*. Identity-based policies can be further categorized as *inline policies* or *managed policies*. Inline policies are embedded directly into a single user, group, or role. Managed policies are standalone policies that you can attach to multiple users, groups, and roles in your AWS account. Managed policies include AWS managed policies and customer managed policies. To learn how to choose between a managed policy or an inline policy, see [Choosing between managed policies and inline policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#choosing-managed-or-inline) in the *IAM User Guide*. ### Resource-based policies Resource-based policies are JSON policy documents that you attach to a resource such as an Amazon S3 bucket. Service administrators can use these policies to define what actions a specified principal (account member, user, or role) can perform on that resource and under what conditions. Resource-based policies are inline policies. There are no managed resource-based policies. ### Access control lists (ACLs) Access control lists (ACLs) are a type of policy that controls which principals (account members, users, or roles) have permissions to access a resource. ACLs are similar to resource-based policies, although they do not use the JSON policy document format. Amazon S3, AWS WAF, and Amazon VPC are examples of services that support ACLs. To learn more about ACLs, see [Access Control List (ACL) overview](https://docs.aws.amazon.com/AmazonS3/latest/dev/acl-overview.html) in the *Amazon Simple Storage Service Developer Guide*. ### Other policy types AWS supports additional, less-common policy types. These policy types can set the maximum permissions granted to you by the more common policy types. + **Permissions boundaries** – A permissions boundary is an advanced feature in which you set the maximum permissions that an identity-based policy can grant to an IAM entity (IAM user or role). You can set a permissions boundary for an entity. The resulting permissions are the intersection of entity’s identity-based policies and its permissions boundaries. Resource-based policies that specify the user or role in the `Principal` field are not limited by the permissions boundary. An explicit deny in any of these policies overrides the allow. For more information about permissions boundaries, see [Permissions boundaries for IAM entities](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) in the *IAM User Guide*. + **Service control policies (SCPs)** – SCPs are JSON policies that specify the maximum permissions for an organization or organizational unit (OU) in AWS Organizations. AWS Organizations is a service for grouping and centrally managing multiple AWS accounts that your business owns. If you enable all features in an organization, then you can apply service control policies (SCPs) to any or all of your accounts. The SCP limits permissions for entities in member accounts, including each AWS account root user. For more information about Organizations and SCPs, see [How SCPs work](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_about-scps.html) in the *AWS Organizations User Guide*. + **Session policies** – Session policies are advanced policies that you pass as a parameter when you programmatically create a temporary session for a role or federated user. The resulting session’s permissions are the intersection of the user or role’s identity-based policies and the session policies. Permissions can also come from a resource-based policy. An explicit deny in any of these policies overrides the allow. For more information, see [Session policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) in the *IAM User Guide*. ### Multiple policy types When multiple types of policies apply to a request, the resulting permissions are more complicated to understand. To learn how AWS determines whether to allow a request when multiple policy types are involved, see [Policy evaluation logic](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) in the *IAM User Guide*. # How AWS Security Agent works with IAM Before you use IAM to manage access to AWS Security Agent, learn what IAM features are available to use with AWS Security Agent. | IAM feature | AWS Security Agent support | | --- | --- | | [Identity-based policies for AWS Security Agent](#security_iam_service-with-iam-id-based-policies) | Yes | | [Resource-based policies within AWS Security Agent](#security_iam_service-with-iam-resource-based-policies) | No | | [Policy actions for AWS Security Agent](#security_iam_service-with-iam-id-based-policies-actions) | Yes | | [Policy resources for AWS Security Agent](#security_iam_service-with-iam-id-based-policies-resources) | Partial | | [Policy condition keys for AWS Security Agent](#security_iam_service-with-iam-id-based-policies-conditionkeys) | Yes | | [Access control lists (ACLs) in AWS Security Agent](#security_iam_service-with-iam-acls) | No | | [Attribute-based access control (ABAC) with AWS Security Agent](#security_iam_service-with-iam-tags) | No | | [Using temporary credentials with AWS Security Agent](#security_iam_service-with-iam-roles-tempcreds) | Yes | | [Forward access sessions for AWS Security Agent](#security_iam_service-with-iam-principal-permissions) | Yes | | [Service roles for AWS Security Agent](#security_iam_service-with-iam-roles-service) | No | | [Service-linked roles for AWS Security Agent](#security_iam_service-with-iam-roles-service-linked) | Yes | To get a high-level view of how AWS Security Agent and other AWS services work with IAM, see [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) in the *IAM User Guide*. ## Identity-based policies for AWS Security Agent **Supports identity-based policies:** Yes Identity-based policies are JSON permissions policy documents that you can attach to an identity, such as an IAM user, group of users, or role. These policies control what actions users and roles can perform, on which resources, and under what conditions. To learn how to create an identity-based policy, see [Define custom IAM permissions with customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) in the *IAM User Guide*. With IAM identity-based policies, you can specify allowed or denied actions and resources as well as the conditions under which actions are allowed or denied. You can’t specify the principal in an identity-based policy because it applies to the user or role to which it is attached. To learn about all of the elements that you use in a JSON policy, see [IAM JSON policy elements reference](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) in the *IAM User Guide*. ### Identity-based policy examples for AWS Security Agent To view examples of AWS Security Agent identity-based policies, see [AWS Security Agent identity-based policy examples](security-iam-id-based-policy-examples.md). ### Resource-based policies within AWS Security Agent **Supports resource-based policies:** No Resource-based policies are JSON policy documents that you attach to a resource. Examples of resource-based policies are IAM role trust policies and Amazon S3 bucket policies. In services that support resource-based policies, service administrators can use them to control access to a specific resource. For the resource where the policy is attached, the policy defines what actions a specified principal can perform on that resource and under what conditions. You must [specify a principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) in a resource-based policy. Principals can include accounts, users, roles, federated users, or AWS Services. To enable cross-account access, you can specify an entire account or IAM entities in another account as the principal in a resource-based policy. Adding a cross-account principal to a resource-based policy is only half of establishing the trust relationship. When the principal and the resource are in different AWS Accounts, an IAM administrator in the trusted account must also grant the principal entity (user or role) permission to access the resource. They grant permission by attaching an identity-based policy to the entity. However, if a resource-based policy grants access to a principal in the same account, no additional identity-based policy is required. For more information, see [Cross account resource access in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) in the IAM User Guide. ### Policy actions for AWS Security Agent **Supports actions** Yes Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**. The `Action` element of an IAM identity-based policy describes the specific action or actions that will be allowed or denied by the policy. Policy actions usually have the same name as the associated AWS API operation. The action is used in a policy to grant permissions to perform the associated operation. Policy actions in AWS Security Agent use the following prefix before the action: `securityagent:`. For example, to grant someone permission to create an environment with the AWS Security Agent `CreateEnvironment` API operation, you include the `securityagent:CreateEnvironment` action in their policy. Policy statements must include either an `Action` or `NotAction` element. AWS Security Agent defines its own set of actions that describe tasks that you can perform with this service. To specify multiple actions in a single statement, separate them with commas as follows: ``` "Action": [ "securityagent:action1", "securityagent:action2" ``` You can specify multiple actions using wildcards (\$1). For example, to specify all actions that begin with the word `List`, include the following action: ``` "Action": "securityagent:List*" ``` ### Policy resources for AWS Security Agent **Supports policy resources:** Partial Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**. The `Resource` JSON policy element specifies the object or objects to which the action applies. Statements must include either a `Resource` or a `NotResource` element. As a best practice, specify a resource using its Amazon Resource Name (ARN). You can do this for actions that support a specific resource type, known as *resource-level permissions*. For actions that don’t support resource-level permissions, such as listing operations, use a wildcard (\$1) to indicate that the statement applies to all resources. ``` "Resource": "*" ``` Some AWS Security Agent API actions support multiple resources. For example, multiple environments can be referenced when calling the `ListEnvironments` API action. To specify multiple resources in a single statement, separate the ARNs with commas. ``` "Resource": [ "EXAMPLE-RESOURCE-1", "EXAMPLE-RESOURCE-2" ``` For example, the AWS Security Agent environment resource has the following ARN: ``` arn:${Partition}:securityagent:${Region}:${Account}:environment/${EnvironmentId} ``` To specify the environments `my-environment-1` and `my-environment-2` in your statement, use the following example ARNs: ``` "Resource": [ "arn:aws:securityagent:us-east-1:123456789012:environment/my-environment-1", "arn:aws:securityagent:us-east-1:123456789012:environment/my-environment-2" ``` To specify all environments that belong to a specific account, use the wildcard (\$1): ``` "Resource": "arn:aws:securityagent:us-east-1:123456789012:environment/*" ``` ### Policy condition keys for AWS Security Agent **Supports service-specific policy condition keys:** Yes Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**. The `Condition` element (or `Condition` block) lets you specify conditions in which a statement is in effect. The `Condition` element is optional. You can create conditional expressions that use [condition operators](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), such as equals or less than, to match the condition in the policy with values in the request. If you specify multiple `Condition` elements in a statement, or multiple keys in a single `Condition` element, AWS evaluates them using a logical `AND` operation. If you specify multiple values for a single condition key, AWS evaluates the condition using a logical `OR` operation. All of the conditions must be met before the statement’s permissions are granted. You can also use placeholder variables when you specify conditions. For example, you can grant an IAM user permission to access a resource only if it is tagged with their IAM user name. For more information, see [IAM policy elements: variables and tags](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html) in the *IAM User Guide*. AWS Security Agent defines its own set of condition keys and also supports using some global condition keys. To see all AWS global condition keys, see [AWS global condition context keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) in the *IAM User Guide*. ## Access control lists (ACLs) in AWS Security Agent **Supports ACLs:** No Access control lists (ACLs) control which principals (account members, users, or roles) have permissions to access a resource. ACLs are similar to resource-based policies, although they do not use the JSON policy document format. ## Attribute-based access control (ABAC) with AWS Security Agent **Supports ABAC (tags in policies):** No ## Using temporary credentials with AWS Security Agent **Supports temporary credentials:** Yes Some AWS Services don’t work when you sign in using temporary credentials. For additional information, including which AWS Services work with temporary credentials, see [AWS Services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) in the *IAM User Guide*. You are using temporary credentials if you sign in to the AWS Management Console using any method except a user name and password. For example, when you access AWS using your company’s single sign-on (SSO) link, that process automatically creates temporary credentials. You also automatically create temporary credentials when you sign in to the console as a user and then switch roles. For more information about switching roles, see [Switch from a user to an IAM role (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html) in the *IAM User Guide*. You can manually create temporary credentials using the AWS CLI or AWS API. You can then use those temporary credentials to access AWS. AWS recommends that you dynamically generate temporary credentials instead of using long-term access keys. For more information, see [Temporary security credentials in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html). ## Forward access sessions for AWS Security Agent **Supports forward access sessions (FAS):** Yes When you use an IAM user or role to perform actions in AWS, you are considered a principal. When you use some services, you might perform an action that then initiates another action in a different service. FAS uses the permissions of the principal calling an AWS Service, combined with the requesting AWS Service to make requests to downstream services. FAS requests are only made when a service receives a request that requires interactions with other AWS Services or resources to complete. In this case, you must have permissions to perform both actions. For policy details when making FAS requests, see [Forward access sessions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html). ## Service roles for AWS Security Agent **Supports service roles:** No A service role is an IAM role that a service assumes to perform actions on your behalf. An IAM administrator can create, modify, and delete a service role from within IAM. For more information, see [Create a role to delegate permissions to an AWS Service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) in the *IAM User Guide*. ## Service-linked roles for AWS Security Agent **Supports service-linked roles:** Yes A service-linked role is a type of service role that is linked to an AWS Service. The service can assume the role to perform an action on your behalf. Service-linked roles appear in your AWS Account and are owned by the service. An IAM administrator can view, but not edit the permissions for service-linked roles. # AWS Security Agent identity-based policy examples By default, IAM users and roles don’t have permission to create or modify AWS Security Agent resources. They also can’t perform tasks using the AWS Management Console, AWS CLI, or AWS API. An IAM administrator must create IAM policies that grant users and roles permission to perform specific API operations on the specified resources they need. The administrator must then attach those policies to the IAM users or groups that require those permissions. To learn how to create an IAM identity-based policy using these example JSON policy documents, see [Creating policies using the JSON editor](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html#access_policies_create-json-editor) in the *IAM User Guide*. ## Policy best practices Identity-based policies determine whether someone can create, access, or delete AWS Security Agent resources in your account. These actions can incur costs for your AWS account. When you create or edit identity-based policies, follow these guidelines and recommendations: + **Get started with AWS managed policies and move toward least-privilege permissions** – To get started granting permissions to your users and workloads, use the AWS managed policies that grant permissions for many common use cases. They are available in your AWS account. We recommend that you reduce permissions further by defining AWS customer managed policies that are specific to your use cases. For more information, see [AWS managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) or [AWS managed policies for job functions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) in the *IAM User Guide*. + **Apply least-privilege permissions** – When you set permissions with IAM policies, grant only the permissions required to perform a task. You do this by defining the actions that can be taken on specific resources under specific conditions, also known as *least-privilege permissions*. For more information about using IAM to apply permissions, see [Policies and permissions in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) in the *IAM User Guide*. + **Use conditions in IAM policies to further restrict access** – You can add a condition to your policies to limit access to actions and resources. For example, you can write a policy condition to specify that all requests must be sent using SSL. You can also use conditions to grant access to service actions if they are used through a specific AWS service, such as CloudFormation. For more information, see [IAM JSON policy elements: condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) in the *IAM User Guide*. + **Use IAM Access Analyzer to validate your IAM policies to ensure secure and functional permissions** – IAM Access Analyzer validates new and existing policies so that the policies adhere to the IAM policy language (JSON) and IAM best practices. IAM Access Analyzer provides more than 100 policy checks and actionable recommendations to help you author secure and functional policies. For more information, see [IAM Access Analyzer policy validation](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) in the *IAM User Guide*. + **Require multi-factor authentication (MFA)** – If you have a scenario that requires IAM users or root users in your account, turn on MFA for additional security. To require MFA when API operations are called, add MFA conditions to your policies. For more information, see [Configuring MFA-protected API access](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) in the *IAM User Guide*. ## Using the AWS Security Agent console To access the AWS Security Agent console, an IAM principal must have a minimum set of permissions. These permissions must allow the principal to list and view details about the AWS Security Agent resources in your AWS account. If you create an identity-based policy that is more restrictive than the minimum required permissions, the console won’t function as intended for principals with that policy attached to them. To ensure that your IAM principals can still use the AWS Security Agent console, create a policy with your own unique name. Attach the policy to the principals. For more information, see [Adding permissions to a user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) in the *IAM User Guide*: For policy details, see [AWS managed policy: SecurityAgentWebAppAPIPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-SecurityAgentWebAppAPIPolicy). You don’t need to allow minimum console permissions for users that are making calls only to the AWS CLI or the AWS API. Instead, allow access to only the actions that match the API operation that you’re trying to perform. # Troubleshooting AWS Security Agent identity and access Use the following information to help you diagnose and fix common issues that you might encounter when working with AWS Security Agent and IAM. ## AccessDeniedException If you receive an `AccessDeniedException` when calling an AWS API operation, then the IAM principal credentials that you’re using don’t have the required permissions to make that call. ``` An error occurred (AccessDeniedException) when calling the CreateEnvironment operation: User: arn:aws:iam::111122223333:user/user_name is not authorized to perform: securityagent:CreateEnvironment on resource: arn:aws:securityagent:region:111122223333:environment/my-env ``` In the previous example message, the user does not have permissions to call the AWS Security Agent `CreateEnvironment` API operation. To provide AWS Security Agent admin permissions to an IAM principal, see [AWS Security Agent identity-based policy examples](security-iam-id-based-policy-examples.md). For more general information about IAM, see [Control access to AWS resources using policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html) in the *IAM User Guide*. ## I want to allow people outside of my AWS account to access my AWS Security Agent resources You can create a role that users in other accounts or people outside of your organization can use to access your resources. You can specify who is trusted to assume the role. For services that support resource-based policies or access control lists (ACLs), you can use those policies to grant people access to your resources. To learn more, consult the following: + To learn whether AWS Security Agent supports these features, see [How AWS Security Agent works with IAM](security_iam_service-with-iam.md). + To learn how to provide access to your resources across AWS accounts that you own, see [Providing access to an IAM user in another AWS account that you own](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) in the *IAM User Guide*. + To learn how to provide access to your resources to third-party AWS accounts, see [Providing access to AWS accounts owned by third parties](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) in the *IAM User Guide*. + To learn how to provide access through identity federation, see [Providing Access to Externally Authenticated Users (Identity Federation)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) in the *IAM User Guide*. + To learn the difference between using roles and resource-based policies for cross-account access, see [How IAM roles differ from resource-based policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_compare-resource-policies.html) in the *IAM User Guide*. # Incident response AWS Security Agent is a proactive security testing service designed to identify and prevent vulnerabilities before they can be exploited. The service focuses on preventative security validation through design reviews, code analysis, and penetration testing rather than reactive incident detection or response. ## Incident detection AWS Security Agent does not provide incident detection capabilities. The service operates as a proactive security testing tool that validates applications for vulnerabilities during development and before deployment. For runtime security monitoring and incident detection, use services such as Amazon GuardDuty, AWS Security Hub, or Amazon CloudWatch. ## Incident alerting AWS Security Agent does not generate real-time alerts for security incidents. The service delivers security findings through the AWS Console after completing design reviews, code analyses, or penetration testing engagements. These findings represent potential vulnerabilities discovered during testing rather than active security incidents. ## Incident remediation AWS Security Agent does not provide automated incident remediation. The service identifies security vulnerabilities and provides remediation guidance, including: + Detailed descriptions of identified vulnerabilities + Reproducible exploit paths for validated findings + Specific code fixes and implementation guidance + Impact analysis for discovered issues Development and security teams use this guidance to manually address vulnerabilities before they reach production environments. ## Supporting incident response activities While AWS Security Agent is not designed for incident response, security teams can use the service to support post-incident activities: **Vulnerability validation** After a security incident, use AWS Security Agent to test whether similar vulnerabilities exist in other applications or environments. **Security posture assessment** Conduct penetration testing to validate security improvements implemented as part of incident remediation. **Root cause analysis** Use code security review capabilities to identify how similar vulnerabilities might exist in other codebases. # Compliance validation for AWS Security Agent Compliance validation To learn whether an AWS service is within the scope of specific compliance programs, see [AWS services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/) and choose the compliance program that you are interested in. For general information, see [AWS Compliance Programs](https://aws.amazon.com/compliance/programs/). You can download third-party audit reports using AWS Artifact. For more information, see [Downloading Reports in AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html). Your compliance responsibility when using AWS services is determined by the sensitivity of your data, your company’s compliance objectives, and applicable laws and regulations. AWS provides the following resources to help with compliance: + [Security Compliance & Governance](https://aws.amazon.com/solutions/security/security-compliance-governance/) – These solution implementation guides discuss architectural considerations and provide steps for deploying security and compliance features. + [HIPAA Eligible Services Reference](https://aws.amazon.com/compliance/hipaa-eligible-services-reference/) – Lists HIPAA eligible services. Not all AWS services are HIPAA eligible. + [AWS Compliance Resources](https://aws.amazon.com/compliance/resources/) – This collection of workbooks and guides might apply to your industry and location. + [AWS Customer Compliance Guides](https://d1.awsstatic.com/whitepapers/compliance/AWS_Customer_Compliance_Guides.pdf) – Understand the shared responsibility model through the lens of compliance. The guides summarize the best practices for securing AWS services and map the guidance to security controls across multiple frameworks (including National Institute of Standards and Technology (NIST), Payment Card Industry Security Standards Council (PCI), and International Organization for Standardization (ISO)). + [Evaluating Resources with Rules](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) in the *AWS Config Developer Guide* – The AWS Config service assesses how well your resource configurations comply with internal practices, industry guidelines, and regulations. + [AWS Security Hub](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) – This AWS service provides a comprehensive view of your security state within AWS. Security Hub uses security controls to evaluate your AWS resources and to check your compliance against security industry standards and best practices. For a list of supported services and controls, see [Security Hub controls reference](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-controls-reference.html). + [Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/what-is-guardduty.html) – This AWS service detects potential threats to your AWS accounts, workloads, containers, and data by monitoring your environment for suspicious and malicious activities. GuardDuty can help you address various compliance requirements, like PCI DSS, by meeting intrusion detection requirements mandated by certain compliance frameworks. + [AWS Audit Manager](https://docs.aws.amazon.com/audit-manager/latest/userguide/what-is.html) – This AWS service helps you continuously audit your AWS usage to simplify how you manage risk and compliance with regulations and industry standards. # Resilience in AWS Security Agent Resilience **Note** AWS Security Agent is available in `us-east-1`, `us-west-2`, `eu-west-1`, `eu-central-1`, `ap-southeast-2`, and `ap-northeast-1`. It uses [geographic cross region inference](https://docs.aws.amazon.com/bedrock/latest/userguide/geographic-cross-region-inference.html). AWS Security Agent is a tool used during the development of your application, and should not be deployed as critical or customer facing infrastructure. The AWS global infrastructure is built around AWS Regions and Availability Zones. AWS Regions provide multiple physically separated and isolated Availability Zones, which are connected with low-latency, high-throughput, and highly redundant networking. With Availability Zones, you can design and operate applications and databases that automatically fail over between zones without interruption. Availability Zones are more highly available, fault tolerant, and scalable than traditional single or multiple data center infrastructures. For more information about AWS Regions and Availability Zones, see [AWS Global Infrastructure](https://aws.amazon.com/about-aws/global-infrastructure/). # Infrastructure security in AWS Security Agent Infrastructure security As a managed service, AWS Security Agent is protected by AWS global network security. For information about AWS security services and how AWS protects infrastructure, see [AWS Cloud Security](https://aws.amazon.com/security/). To design your AWS environment using the best practices for infrastructure security, see [Security](https://aws.amazon.com/architecture/security-identity-compliance/) in the *AWS Well-Architected Framework*. ## Network isolation AWS Security Agent is a fully managed service accessed through the AWS Console and AWS Security Agent Web Application. Access to the service is controlled through AWS Identity and Access Management (IAM) or AWS IAM Identity Center, which can integrate with your identity provider. The service does not support VPC endpoints or deployment within customer VPCs, and cannot be restricted to specific subnets through IAM or SCP policies. AWS Security Agent requires internet access to perform penetration testing on target applications and for control plane operations. The service does not create customer-owned resources with public IP addresses. ## Multi-tenancy and resource isolation AWS Security Agent is a multi-tenant service. Security reviews, findings, and customer data are isolated to individual AWS accounts and encrypted at rest. AWS applies standard infrastructure isolation controls to ensure that one customer’s security testing activities do not impact another customer’s performance or confidentiality. # Configuration and vulnerability analysis in AWS Security Agent Configuration and vulnerability analysis Configuration and IT controls are a shared responsibility between AWS and you, our customer. For more information, see the AWS [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/). # Cross-service confused deputy prevention Cross-service confused deputy prevention The confused deputy problem is a security issue where an entity that doesn’t have permission to perform an action can coerce a more-privileged entity to perform the action. In AWS, cross-service impersonation can result in the confused deputy problem. Cross-service impersonation can occur when one service (the *calling service*) calls another service (the *called service*). The calling service can be manipulated to use its permissions to act on another customer’s resources in a way it should not otherwise have permission to access. To prevent this, AWS provides tools that help you protect your data for all services with service principals that have been given access to resources in your account. For more information, see [Cross-service confused deputy prevention](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html#cross-service-confused-deputy-prevention) in the AWS Identity and Access Management User Guide. # Security best practices for AWS Security Agent Security best practices 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. # IAM actions and resources migration IAM actions and resources migration AWS Security Agent is a frontier agent that proactively secures your applications throughout the development lifecycle across all your environments. If you onboarded to AWS Security Agent prior to February 9, 2026, you will be impacted by upcoming changes on March 9, 2026 to your existing Agent Instance resources and AWS Security Agent IAM actions. In preparation for releasing public API/SDK support, the Agent Instance resource is being renamed to Agent Space, and specific IAM actions are being renamed. These changes will affect any Application or Agent Instances IAM roles you have created prior to March 9, 2026. In order to avoid seeing authentication issues after March 9, 2026, you will need to follow the steps under Preparing for Migration. **Note** If you create any new Agent Instances after February 9, 2026, the new Agent Instance will be created as an Agent Space and no migration steps will be required. ## Planned Changes AWS Security Agent is renaming the Agent Instance resource to Agent Space: `arn:aws:securityagent:us-east-1:{{accountId}}:agent-instance/*` renamed to `arn:aws:securityagent:us-east-1:{{accountId}}:agent-space/*`. Additionally, the following IAM actions are being renamed: + `securityagent:ListAgentInstances` renamed to `securityagent:ListAgentSpaces` + `securityagent:ListControls` renamed to `securityagent:ListSecurityRequirements` + `securityagent:BatchGetAgentInstances` renamed to `securityagent:BatchGetAgentSpaces` + `securityagent:BatchGetSecurityTestContentMetadata` renamed to `securityagent:BatchGetPentestJobContentMetadata` + `securityagent:BatchGetTasks` renamed to `securityagent:BatchGetPentestJobTasks` + `securityagent:CreateDocumentReview` renamed to `securityagent:CreateDesignReview` + `securityagent:GetDocumentReview` renamed to `securityagent:GetDesignReview` + `securityagent:GetDocumentReviewArtifact` renamed to `securityagent:GetDesignReviewArtifact` + `securityagent:ListDocumentReviews` renamed to `securityagent:ListDesignReviews` + `securityagent:ListDocumentReviewComments` renamed to `securityagent:ListDesignReviewComments` + `securityagent:ListTasks` renamed to `securityagent:ListPentestJobTasks` + `securityagent:StartPentestExecution` renamed to `securityagent:StartPentestJob` + `securityagent:StopPentestExecution` renamed to `securityagent:StopPentestJob` + `securityagent:DeleteDocumentReview` renamed to `securityagent:DeleteDesignReview` ## Preparing for Migration In order to avoid seeing issues after March 9, 2026 while continuing to use AWS Security Agent prior to March 9, 2026, you will need to **trust both the new and old resources and IAM actions in your IAM roles/policies** until March 9, 2026. The below instructions will provide a guide for migrating to the new resource and action formats: 1. Log in to your AWS account and navigate to the **AWS Security Agent console** 1. In the left hand panel, select **Settings** and click the role under **Service role** 1. In the IAM console for the associated role, select **Add permissions** and **Attach policies** 1. Select **AWSSecurityAgentWebAppPolicy** and click **Add permissions** 1. **Important Note:** Verify that you have selected **AWSSecurityAgentWebAppPolicy** as the new policy and not **SecurityAgentWebAppAPIPolicy** 1. Verify that your IAM role now has both **AWSSecurityAgentWebAppPolicy** and **SecurityAgentWebAppAPIPolicy** under **Permissions policies** 1. In the same IAM role console, select **Trust relationships** then **Edit trust policy** 1. Update your trust policy to the following format, replacing **\$1\$1accountId\$1\$1** with your AWS account ID ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "securityagent.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "{{accountId}}" }, "ArnLike": { "aws:SourceArn": [ "arn:aws:securityagent:us-east-1:{{accountId}}:application/*", "arn:aws:securityagent:us-east-1:{{accountId}}:agent-space/*", "arn:aws:securityagent:us-east-1:{{accountId}}:agent-instance/*" ] } } }, { "Effect": "Allow", "Principal": { "Service": "securityagent.amazonaws.com" }, "Action": "sts:SetContext", "Condition": { "StringEquals": { "aws:SourceAccount": "{{accountId}}" }, "ForAllValues:ArnEquals": { "sts:RequestContextProviders": "arn:aws:iam::aws:contextProvider/IdentityCenter" }, "ArnLike": { "aws:SourceArn": [ "arn:aws:securityagent:us-east-1:{{accountId}}:application/*", "arn:aws:securityagent:us-east-1:{{accountId}}:agent-space/*", "arn:aws:securityagent:us-east-1:{{accountId}}:agent-instance/*" ] } } } ] } ``` 1. Navigate back to the **AWS Security Agent console**. From the left-hand panel, select **Agent Spaces** 1. For each Agent Space you have with penetration testing enabled, perform the following steps 1. Navigate to the Agent Space and select **Penetration test** 1. Scroll down to **Service access** and click the role under **Service role name** 1. In the IAM console for the associated role, select **Trust relationships** then **Edit trust policy** 1. Update your trust policy to the following format, replacing **\$1\$1accountId\$1\$1** with your AWS account ID ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "securityagent.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "{{accountId}}" }, "ArnLike": { "aws:SourceArn": [ "arn:aws:securityagent:us-east-1:{{accountId}}:agent-space/*", "arn:aws:securityagent:us-east-1:{{accountId}}:agent-instance/*" ] } } } ] } ``` # Logging AWS Security Agent API calls with AWS CloudTrail Logging with CloudTrail AWS Security Agent is integrated with AWS CloudTrail, a service that provides a record of actions taken by a user, role, or an AWS service in AWS Security Agent. CloudTrail captures all API calls for AWS Security Agent as events. The calls captured include calls from the AWS Security Agent console and code calls to the AWS Security Agent API operations. If you create a trail, you can enable continuous delivery of CloudTrail events to an Amazon S3 bucket, including events for AWS Security Agent. If you don’t configure a trail, you can still view the most recent events in the CloudTrail console in **Event history**. Using the information collected by CloudTrail, you can determine the request that was made to AWS Security Agent, the IP address from which the request was made, who made the request, when it was made, and additional details. To learn more about CloudTrail, see the [AWS CloudTrail User Guide](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html). ## AWS Security Agent information in CloudTrail CloudTrail is enabled on your AWS account when you create the account. When activity occurs in AWS Security Agent, that activity is recorded in a CloudTrail event along with other AWS service events in **Event history**. You can view, search, and download recent events in your AWS account. For more information, see [Viewing events with CloudTrail Event history](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html). For an ongoing record of events in your AWS account, including events for AWS Security Agent, create a trail. A *trail* enables CloudTrail to deliver log files to an Amazon S3 bucket. By default, when you create a trail in the console, the trail applies to all AWS Regions. The trail logs events from all Regions in the AWS partition and delivers the log files to the Amazon S3 bucket that you specify. Additionally, you can configure other AWS services to further analyze and act upon the event data collected in CloudTrail logs. For more information, see the following: + [Overview for creating a trail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html) + [CloudTrail supported services and integrations](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-aws-service-specific-topics.html) + [Configuring Amazon SNS notifications for CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/configure-sns-notifications-for-cloudtrail.html) + [Receiving CloudTrail log files from multiple regions](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-log-files-from-multiple-regions.html) and [Receiving CloudTrail log files from multiple accounts](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-receive-logs-from-multiple-accounts.html) All AWS Security Agent actions are logged by CloudTrail. For example, calls to the `CreatePentest`, `BatchGetPentestJobs`, and `ListFindings` actions generate entries in the CloudTrail log files. Every event or log entry contains information about who generated the request. The identity information helps you determine the following: + Whether the request was made with root or AWS Identity and Access Management (IAM) user credentials. + Whether the request was made with temporary security credentials for a role or federated user. + Whether the request was made by another AWS service. For more information, see the [CloudTrail userIdentity element](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html). # Example: AWS Security Agent log file entries Example: AWS Security Agent log file entries ## Understanding AWS Security Agent log file entries A trail is a configuration that enables delivery of events as log files to an Amazon S3 bucket that you specify. CloudTrail log files contain one or more log entries. An event represents a single request from any source and includes information about the requested action, the date and time of the action, request parameters, and so on. CloudTrail log files aren’t an ordered stack trace of the public API calls, so they don’t appear in any specific order. The following example shows a CloudTrail log entry that demonstrates the `CreatePentest` action: ``` { "eventVersion": "1.08", "userIdentity": { "type": "IAMUser", "principalId": "AIDACKCEVSQ6C2EXAMPLE", "arn": "arn:aws:iam::123456789012:user/Alice", "accountId": "123456789012", "accessKeyId": "AKIAIOSFODNN7EXAMPLE", "userName": "Alice" }, "eventTime": "2025-01-15T10:30:00Z", "eventSource": "securityagent.amazonaws.com", "eventName": "CreatePentest", "awsRegion": "us-east-1", "sourceIPAddress": "203.0.113.12", "userAgent": "aws-cli/2.13.0", "requestParameters": { "pentestName": "WebApp-Security-Test", "targetUrl": "https://example.com", "testScope": "OWASP-Top-10" }, "responseElements": { "pentestId": "pt-1234567890abcdef0", "pentestArn": "arn:aws:securityagent:us-east-1:123456789012:pentest/pt-1234567890abcdef0" }, "requestID": "a1b2c3d4-e5f6-7890-abcd-ef1234567890", "eventID": "12345678-1234-1234-1234-123456789012", "readOnly": false, "eventType": "AwsApiCall", "managementEvent": true, "recipientAccountId": "123456789012", "eventCategory": "Management" } ```