AWS DevOps Agent Security
This document provides information about security considerations, data protection, access controls, and compliance capabilities for AWS DevOps Agent. Use this information to understand how AWS DevOps Agent is designed to meet your security and compliance requirements.
Agent Spaces
Agent Spaces serve as the primary security boundary in AWS DevOps Agent. Each Agent Space:
Operates independently with its own configurations and permissions
Defines which AWS accounts and resources the agent can access
Establishes connections to third-party platforms
Agent Spaces maintain strict isolation to ensure security and prevent unintended access across different environments or teams.
Regional processing and data flow
AWS DevOps Agent operates from the US East (N. Virginia) region (us-east-1) as its primary processing hub. The agent retrieves operational data from AWS regions across all AWS accounts granted access within the configured Agent Space. This multi-region cross-account data collection ensures comprehensive incident analysis.
Amazon Bedrock usage and cross-region inference
AWS DevOps Agent will automatically select the optimal region within the US to process your inference requests. This maximizes available compute resources, model availability, and delivers the best customer experience. Your data will remain stored in the US East (N. Virginia) region, but inputs, requests, and output may be processed in other US regions. All data will be transmitted encrypted across Amazon's secure network.
DevOps Agent and Bedrock are not impacted by customer policies in Service Control Policies (SCPs) or Control Tower that restrict customer content to specific regions
Bedrock may use U.S. regions other than US East (N. Virginia) to perform stateless inference to optimize performance and availability
Identity and access management
Authentication methods
AWS DevOps Agent provides two authentication methods to log into the AWS DevOps Agent Space web app:
IAM Identity Center integration – The primary authentication method uses OAuth 2.0 with session-based authentication using HTTP-only cookies. IAM Identity Center can federate with external identity providers through standard OIDC and SAML protocols, including providers like Okta, Ping Identity, and Microsoft Entra ID. This method supports multi-factor authentication through your identity provider. IAM Identity Center defaults to session durations of up to 12 hours and can be configured to a desired duration.
IAM authentication link – An alternative method provides direct access to the web app from the AWS Management Console using JWT-based tokens derived from an existing AWS Management Console session. This option is useful for evaluating AWS DevOps Agent before implementing full IAM Identity Center integration as well as gaining administrative access if the AWS DevOps Agent web app becomes inaccessible through IAM Identity Center based authentication. Sessions are limited to 30 minutes.
IAM roles
AWS DevOps Agent uses IAM roles to define access permissions:
Primary account role – Grants the agent access to resources in the AWS account where you create the Agent Spaceas well as access to secondary account roles.
Secondary account roles – Grants the agent access to resources in additional AWS accounts connected to the Agent Space.
Web app role – Grants users access to AWS DevOps Agent investigation data and findings in the web app.
These roles should be configured following the principle of least privilege, granting only the necessary read-only permissions required for investigations.
Data protection
Data encryption
AWS DevOps Agent encrypts all customer data:
Encryption at rest – All data is encrypted with AWS-managed keys.
Encryption in transit – All retrieved logs, metrics, knowledge items, ticket metadata, and other data are encrypted in transit inside the agent's private network and to outside networks.
Data storage and retention
Data is stored in the US East (N. Virginia) region
Personal identifiable information (PII)
AWS DevOps Agent does not filter PII information when summarizing data gathered during investigations, recommendation evaluations, or chat responses. It is recommended that PII data be redacted before storing in observability logs.
Agent journal and audit logging
Agent journal
Both the Incident Investigation and Preventioncapabilities maintain detailed journals that:
Log every reasoning step and action taken
Create complete transparency into agent decision-making processes
Cannot be modified by the agents once recorded, minimizing attacks such as prompt injection from hiding important actions
Include all chat messages from the Investigation page
AWS CloudTrail integration
All AWS DevOps Agent API calls are automatically captured by AWS CloudTrail within the hosting AWS account. Using the information collected by CloudTrail, you can determine:
The request that was made to the agent
The IP address from which the request was made
Who made the request
When it was made
Prompt injection protection
A prompt injection attack occurs when an attacker embeds malicious instructions into external data, such as a webpage or document, that a generative AI system will later process. AWS DevOps Agent natively consumes many data sources as part of its normal operations, including logs, resource tags, and other operational data. AWS DevOps Agent protects against prompt injection attacks through the safeguards below, but it is important to ensure all connected data sources and user access to those data sources are trusted. See AWS DevOps Agent Security section for more. Prompt injection safeguards:
Limited write capabilities – The tools available to the agent are not able to mutate resources, with the exception of opening tickets and support cases. This prevents malicious instructions from modifying your infrastructure or applications.
Account boundary enforcement – AWS DevOps Agent only operates within the boundary permitted by the roles assigned to the agent in the primary and connected secondary AWS accounts. The agent cannot access or modify resources outside of its configured scope.
AI safety protections – AWS DevOps Agent uses Claude Sonnet 4.5, which includes AI Safety Level 3 (ASL-3) protections. These protections include classifiers that detect and prevent prompt injection attacks before they can affect agent behavior.
Immutable audit trail – The agent journal logs every reasoning step and action taken. Journal entries cannot be modified by the agent once recorded, preventing prompt injection attacks from hiding malicious actions.
While AWS DevOps Agent provides multiple layers of protection against prompt injection attacks, certain configurations can increase risk:
Custom MCP server tools – The bring-your-own MCP feature allows you to introduce custom tools to the agent, which can present additional opportunities for prompt injection. Custom tools may not have the same security controls as native AWS DevOps Agent tools, and malicious instructions could potentially leverage these tools in unintended ways. See AWS DevOps Agent Security section for more.
Authorized user attacks – Users who are authorized to operate within the AWS account boundary or connected tools have a higher chance of attempting an attack against the agent. These users may have the ability to modify data sources that the agent consumes, such as logs or resource tags, making it easier to embed malicious instructions that the agent will process.
To mitigate these risks:
Carefully review and test custom MCP servers before deploying them in Agent Spaces.
Ensure they are only permitted to perform read-only actions
Verify that users of external tools accessed by MCP servers are trusted entities, as AWS DevOps Agents interfacing with MCP rely on the implicit trust relationship established between these tool users and the AWS DevOps Agent
Apply the principle of least privilege when granting users access to systems that provide data to the agent
Regularly audit which MCP servers are connected to your Agent Spaces
Since any content retrieved from allowlisted URLs could attempt to manipulate the agent's behavior, only include trusted sources in your allowlist.
Integration security
AWS DevOps Agent supports several integration types, each with its own security model:
Native bidirectional integrations – Built-in integrations that can send data to the agent and receive updates from the agent. This uses the vendor’s authentication methods
MCP servers – Remote Model Context Protocol servers that utilize OAuth 2.0 authentication flows and API keys to securely communicate with external systems.
Webhook triggers – Investigation triggers from remote services such as tickets or observability systems. Webhooks use Hash-based Message Authentication Code (HMAC) for security.
Outbound communication – Integrations like Slack and ticketing systems receive updates from the agent but do not yet support bidirectional communication.
Registration providers
Some external tools are authenticated at the account level and shared among all Agent Spaces in the account. When you register these tools, you authenticate once at the account level, and then each Agent Space can connect to specific resources within that registered connection. The following tools use account-level registration:
GitHub – Uses OAuth flow for authentication. After registering GitHub at the account level, each Agent Space can connect to specific repositories within your GitHub organization.
Dynatrace – Uses OAuth token authentication. After registering Dynatrace at the account level, each Agent Space can connect to specific Dynatrace environments or monitoring configurations.
Slack – Uses OAuth token authentication. After registering Slack at the account level, each Agent Space can connect to specific Slack channels.
Datadog – Uses MCP with OAuth flow for authentication. After registering Datadog at the account level, each Agent Space can connect to specific Datadog monitoring resources.
New Relic – Uses API key authentication. After registering New Relic at the account level, each Agent Space can connect to specific New Relic monitoring configurations.
Splunk – Uses bearer token authentication. After registering Splunk at the account level, each Agent Space can connect to specific Splunk data sources.
GitLab – Uses access token authentication. After registering GitLab at the account level, each Agent Space can connect to specific GitLab repositories.
ServiceNow – Uses OAuth client key/token authentication. After registering ServiceNow at the account level, each Agent Space can connect to specific ServiceNow instances or ticket queues.
General public accessible remote MCP servers – Use OAuth flow for authentication. After registering a remote MCP server at the account level, each Agent Space can connect to specific resources exposed by that server.
Network connectivity
AWS DevOps Agent connects to third-party systems, including remote MCP servers, from the following public IP addresses:
34.228.181.128
44.219.176.187
54.226.244.221
If your third-party systems or remote MCP servers use IP allowlisting or firewall rules, you must allow inbound connections from these IP addresses to enable AWS DevOps Agent to access your integrations.
Shared responsibility model
AWS responsibilities
AWS is responsible for:
Maintaining the security of data retrieved by the agent
Securing native tools available for use by the agent
Protecting the infrastructure that runs AWS DevOps Agent
Customer responsibilities
Customers areresponsiblefor:
Managing user access to theagent space
Limiting access to trusted users of external systems that provide inputs to the agent, such as services and resources that produce logs, CloudTrail events, tickets, and more – that may be used to attempt malicious prompt injection.
Ensure all connected data sources have trusted data that is unlikely to be used to attempt prompt injection attacks
Ensuring bring-your-own MCP server integrations operate securely
Ensuring IAM roles assigned to the agent are properly scoped
Redacting PII data before storing in observability logs and other agent data sources
Following the recommended practice of granting only read-only permissions to connected data sources, including bring-your-own MCP servers
Data usage
AWS does not use agent data, chat messages, or data from integrated data sources to train models or improve the product. The AWS DevOps Agent Space uses customer in-product feedback to improve the agent’s responses and investigations, but AWS does not use it to improve the service itself.
Compliance
At preview, AWS DevOps Agent is not compliant with standards including SOC 2, PCI-DSS, ISO 27001, or FedRAMP. AWS will announce which compliance certifications will be available at a later time.
