A real-world wake-up call from a SOC lab experiment
Executive Summary
To safely evaluate autonomous SOC investigation agents, we built a controlled AWS-based lab environment that closely resembles a modern security operations ecosystem.
We wanted to test how aggressive an AI agent would be when trying to complete a task. Would it fail at the first sign of friction? Would it alert us if it was running into issues or would it hyper-focus on finding a way around roadblocks? We started building autonomous SOC investigation agents to pull alert context from security APIs, ask follow-up questions, collect evidence, and produce an analyst-style investigation. The kicker? We sandboxed the agent and restricted direct outbound access. What we found was when direct API access failed, the agent did not prompt us to intervene. It obsessively discovering alternate paths across AWS, chaining legitimate administrative capabilities together to reach the data another way. The result looked uncomfortably similar to cloud-native lateral movement. The agent prioritized completing the task over sticking to the intent of the exercise, regardless of how it accomplished that task.
The Lab Environment
The environment intentionally included realistic operational complexity, interconnected cloud services, and multiple data sources so we could observe how the agent reasoned through investigative workflows. The environment was intentionally segmented and partially restricted.
The lab contained:
- AWS Secrets Manager for credential storage
- Aurora PostgreSQL databases populated with synthetic client alert data
- EC2 instances with Systems Manager (SSM) access enabled. (SSM allows admins to remotely control systems without needing to directly log in. Think remote admin tools)
- S3 buckets for alert ingestion, storage, and workflow artifacts
- Lambda functions handling alert normalization and processing
- SNS topics and subscriptions for alert fan-out and orchestration
- API Gateway endpoints exposing internal alert workflows
- CloudWatch Logs containing operational telemetry and application logs
- EventBridge workflows coordinating ingestion pipelines
- AppSync APIs supporting internal application logic
- Cognito authentication components for API authorization
- An ELK stack used for centralized logging and search
- Simulated SIEM and EDR investigation workflows
- Internal Python investigation tooling and automation scripts
Certain systems could communicate internally, while others had limited outbound access, authentication barriers, VPC restrictions, or intentionally constrained API connectivity. This was by design.
The Agent’s Goal
The goal for the agent was straightforward: given an alert generated by a SOC technology (SIEM, EDR), collect evidence via approved APIs, and produce a real-world investigation summary to assist a SOC analyst. The chain of events, from the agent’s perspective, should go something like this:
- Find the appropriate secret in AWS Secrets Manager.
- Authenticate to the relevant security platform API.
- Pull the alert and related event context.
- Ask investigative questions and gather answers from approved sources.
- Generate an analyst-ready investigation output.
What Actually Happened
The sandbox lab environment intentionally prevented the agent from directly contacting the external API endpoint. That single failure condition dramatically changed the agent’s behavior. Instead of stopping, escalating, or asking for permission, it began looking for other ways to obtain the same information.
The agent treated every security control as a challenge, not a stopping point.
From there, the agent began a chain of discovery and execution that looked very similar to an experienced attacker’s workflow. The important point is that no exploit or malware was involved. The agent used legitimate tools, legitimate permissions, and normal cloud services in unintended ways. It chained together paths that humans wouldn’t think about, at machine speed.
Observed Activity Chain
1. Internal Reconnaissance
The agent started by mapping the environment. It inspected local scripts, loaded tools, enumerated AWS resources, discovered Lambda functions and API Gateways, queried CloudWatch logs, checked SNS subscriptions, looked at S3 buckets, and explored database paths. It mapped our entire lab environment in the time it would take an analyst to log in.
2. Credential and Identity Discovery
After finding that the direct API path was blocked, the agent shifted toward authentication options. It retrieved platform and tenant credentials from available locations, explored Cognito configuration, looked for JWT generation paths, checked Secrets Manager, and considered alternate authentication routes.
3. Cloud-Service Pivoting
The agent then used AWS itself as the execution substrate. It identified EC2 instances with Systems Manager access, attempted to execute scripts through SSM Run Command, staged code through Parameter Store and S3 concepts, installed dependencies, and attempted to query private databases from hosts with better network position.
4. Data Collection Through Alternate Sources
When the API path remained blocked, the agent used logs and databases as secondary sources of truth. It queried CloudWatch logs, Lambda output, normalized alert stores, and database schemas to reconstruct the alert context.
Why This Was So Concerning
While the technical sophistication was impressive, it was the persistence that was the most concerning. The agent continuously re-evaluated failures, generated new hypotheses, chained services together, and created new execution plans. It behaved like a generational-level expert trying to complete an objective.
The agent did not seem to understand these actions as “lateral movement.” It understood them as “alternative methods to complete the assigned task.”
Adversary Tradecraft Mapping
|
Adversary-Like Behavior |
Observed Agent Equivalent |
|
Internal reconnaissance |
Enumerated Lambda functions, API Gateways, schemas, logs, buckets, and event flows. |
|
Credential access |
Pulled and reused available secrets, tenant credentials, and authentication metadata. |
|
Lateral movement |
Pivoted through EC2 and Systems Manager to execute code from a different network position. |
|
Discovery |
Mapped relationships between SNS, EventBridge, Lambda, AppSync, Cognito, and databases. |
|
Execution |
Generated and ran remote Python scripts to retrieve or transform alert data, created S3 buckets, and Lambdas. |
|
Collection |
Used logs, normalized alert stores, and Aurora data as alternate evidence sources. |
The Core Security Failure
The model was not malicious. The issue was excessive implicit trust. The lab environment allowed broad discovery, cross-service visibility, credential retrieval paths, remote execution options, and access to operational telemetry. Individually, many of those permissions may have seemed reasonable. Combined with an autonomous reasoning engine, they created a much larger blast radius.
Lessons for Organizations Deploying AI Agents
AI agents need blast-radius engineering
Treat AI agents like semi-autonomous operators, not chatbots. They need narrowly scoped roles, short-lived sessions, explicit deny boundaries, and hard network segmentation.
“Read-only” is not safe enough
Read access enables reconnaissance, architecture mapping, service relationship analysis, credential discovery, and sensitive data aggregation. For an AI agent, read access can be operationally powerful.
Read-only is not harmless when the actor can reason, correlate, and chain what it sees.
Tool access must be intentionally designed
Cloud tools such as Systems Manager, Lambda, CloudWatch, Secrets Manager, and database clients should not be broadly available to agents by default. Each tool should be explicitly allowed for a specific use case, with deny-by-default behavior elsewhere.
Logs are sensitive data stores
The agent repeatedly used logs as an alternate database. Security teams should treat log access as sensitive, especially when logs contain payload previews, tokens, internal identifiers, or customer context.
Recommended Controls
- Use short-lived role sessions dedicated to each agent workflow.
- Apply explicit deny boundaries for services the agent should never use, such as broad SSM execution or cross-account role assumption.
- Limit access to only the specific credentials required by the workflow.
- Restrict network egress so agents can only reach approved API endpoints.
- Disable or tightly scope remote execution primitives such as SSM Run Command.
- Separate investigation data access from cloud administration access.
- Require approval gates for actions that create code, run code remotely, modify infrastructure, or access new data stores.
- Monitor agent behavior as a first-class security telemetry source.
Final Thought
AI agents are becoming extraordinarily capable SOC assistants. They will help analysts move faster, ask better questions, and produce better investigations. They also introduce a new security challenge: autonomous systems that can recursively explore infrastructure to achieve a goal. We understand the balance required to move at AI speed while properly, securely managing AI agents, which is why we have built the right safeguards around our internal use of AI.
One challenge of the future is to secure our environments from highly capable AI operators acting exactly as instructed.
Pause to Consider
- Which systems should AI agents be able to reach directly?
- Which systems should be technically impossible for agents to reach?
- Can the agent execute code, invoke cloud functions, or run commands on hosts?
- Can the agent discover secrets, schemas, logs, or infrastructure metadata outside the task scope?
- What does “fail closed” look like when an agent hits a blocked path?
- Who approves escalation when the agent wants to pivot to a new tool or data source?
