Your AI SOC Agent Has a Task Role. Does It Also Have Your S3 Credentials?

An audit of an ECS-hosted agentic SOC platform found that 5 of 24 security configuration properties are not covered by existing cloud security benchmarks, including the use of the same IAM role for task and execution roles and read-only consumers holding write credentials. The findings highlight security gaps specific to agentic architectures that predate current benchmarks.

✓ Human-authored analysis; AI used for formatting and proofreading. Agentic security platforms are arriving. ECS-hosted investigation agents that invoke Bedrock models, write case artifacts to S3, mount shared session state via EFS, and expose interactive shells through ALBs. The architecture is sound. The security configuration surface is enormous. Most of it isn't covered by existing benchmarks because the benchmarks were written before agents existed. I audited a published deployment architecture for an ECS-hosted agentic SOC platform. An AI incident response system where autonomous agents triage alerts, investigate incidents, and produce case reports. 24 configuration properties matter for security. I checked each against the control catalog. 19 were already covered. 5 weren't. The 5 gaps reveal a pattern worth understanding even if you never deploy this specific architecture. The architecture has four layers, each with its own security surface: An artifact store S3 holds case data — investigation results, forensic artifacts, evidence files. Public access blocks, access point policies, encryption, transport security, lifecycle rules, and versioning all apply. Standard S3 hardening, but the data is investigation evidence, which means a tampering risk that doesn't exist for typical application data. Session state EFS provides shared filesystem storage across agent tasks. Encryption, IAM authentication no anonymous mounts , TLS enforcement, POSIX identity on access points, and security group restrictions on mount targets. EFS security is less well-understood than S3 — most teams haven't thought about whether their mount target allows NFS traffic from the internet. Compound risks live in task identity ECS . Each agent runs as an ECS task with an IAM role. That role needs Bedrock model invocation, S3 artifact writes, and EFS mounts. The question is whether the permissions are scoped correctly, whether roles are shared across services, and whether a read-only consumer accidentally has write credentials. Exposure controls cover the network surface: no public IPs on ECS tasks, ALB authentication enforcement on interactive shell endpoints, security group restrictions on listener ports, and audit logging for exec sessions. The configuration properties that existing cloud security benchmarks address are well-covered: S3 public access blocks, access point policies, encryption with customer-managed keys, transport encryption, lifecycle rules, and versioning — all have dedicated controls. EFS encryption, IAM authentication, TLS enforcement, and POSIX identity on access points are covered. ECS secrets management, public IP assignment, log configuration, and exec audit logging also covered. ALB authentication actions and security group restrictions are covered. These are table-stakes checks. Every scanner in the market finds these. The interesting findings are in the 5 that weren't covered. Gap 1: Task role and execution role are the same IAM role. ECS task definitions have two role fields: the task role what the application code uses and the execution role what ECS uses to pull container images and push logs . When they're the same role, the application code inherits ECR pull and CloudWatch push permissions it doesn't need. Two trust boundaries collapse into one. The fix is a single property comparison: does taskRoleArn equal executionRoleArn ? Simple check, but no benchmark includes it because the distinction between task roles and execution roles is an ECS-specific concept that predates agentic architectures. Gap 2: Read-only consumer has write credentials. The SOC platform has services that should only read from the artifact store — the reporting service, the dashboard, the evidence viewer. If their task role has s3:PutObject permission, a compromised read-only service can tamper with investigation artifacts. The check requires correlating the ECS task definition which role? with the IAM policy analysis what can that role do? . A cross-resource property that single-resource scanners can't express. The collector resolves the role's IAM policies and stamps a boolean on the ECS observation: has s3 write: true/false . The evaluator checks the boolean. The cross-resource complexity lives in the collector, not in the check. Gap 3: Bedrock model invocation on Resource: . An agent role with bedrock:InvokeModel on all resources can invoke any model in the account — including custom fine-tuned models that may contain training data from other projects. The fix is scoping the resource to specific model ARNs. The existing wildcard detection control covers this, but only if the action is in the sensitive-action registry. Adding bedrock:InvokeModel and the streaming and conversation variants to the registry is the fix. Gap 4: No compound chain linking internet exposure to model invocation. The atomic controls work: "ECS service has public IP" fires. "Role has broad Bedrock invoke" fires. "Role has broad S3 write" fires. Each fires independently. No compound chain connects them into "internet-reachable service can invoke any model AND write to any bucket." The compound path is the blast radius. The individual findings are the components. Gap 5: Artifact tampering through shared storage. One service writes to S3. Another service reads from S3. If the writer is compromised, it can poison the artifacts the reader trusts. No existing chain models this "write → shared store → poison read-only consumer" pattern. It's a data integrity attack, not a data access attack. The chain connects: internet-reachable service has write access, store has no versioning tampered objects overwrite silently , and downstream consumers trust store contents. Every gap is a cross-resource composition. Task role equals execution role compares two fields on one resource. Read-only consumer with write credentials correlates a task definition with an IAM policy. The compound chains connect 3-4 resources into attack paths. Single-resource scanners check each resource independently. Each passes. The compound path is unsafe. The scanner reports green. This is the same structural gap the Hugging Face incident revealed. The sandbox passed every individual check. The escape path was a compound of three configurations that were each individually acceptable. The agentic SOC platform has the same shape: each service is configured correctly. The risk lives in interactions between services. If you're deploying AI agents on ECS or Lambda, or EKS, or any container orchestrator , the configuration surface isn't the individual resource. It's the graph of permissions and network paths connecting the agent's compute, identity, data stores, and exposure points. Five questions for your deployment: Is the task role distinct from the execution role? If the agent's application code inherits ECR and CloudWatch permissions it doesn't need, the blast radius of a compromise is wider than intended. Does every service have its own role? Shared roles mean a compromised triage agent has the same permissions as the investigation agent. Per-service roles limit the blast radius to one function. Is the model invocation scoped to specific models? An agent that can invoke any model can access any fine-tuned model's training data. Scope to the models the agent uses. Can a read-only consumer write to the artifact store? If the reporting service can modify investigation evidence, the integrity of every case report is questionable. The check requires correlating the task role with the IAM policy — not just checking the task definition. If the agent is internet-reachable, what can it reach? The compound path from internet exposure through the agent's role to Bedrock, S3, and EFS is the blast radius. Checking each resource independently misses the path. The 24-item checklist and the 5 gap closures are implemented in Stave, an open-source cloud configuration verification tool. The compound chains that detect cross-resource agent risks require composing findings across ECS, IAM, S3, EFS, and ELB — something single-resource scanners structurally cannot do. Apache 2.0.