AgentCore's Credential Question: What Can the Shell Reach?

TL;DR: AWS documents 2 default Harness tools, shell and file operations, unless the operator restricts them; its microVM isolation separates sessions.^[2][4] LLMRumors' analysis: protecting an agent's credentials also requires deciding which components inside that session may use or read them.

Unit 42's September 18, 2026 report, recirculated on X on October 1, describes prompt injection leading to a shell reading a runtime credential and accessing a simulated downstream service. The researchers say AWS closed their report as informative on June 10.^[1] This October 5 article analyzes the deployment implications.^[9]

The real story isn't whether a credential vault is useful. It is where authority moves after an agent starts working. A support workflow can look narrow to its user while depending on a service identity with substantially broader access. The architecture must preserve that difference when untrusted material enters the workflow.

Our earlier agent-sandbox analysis examined isolation choices across platforms. This case concerns credential authority inside one session, a distinct question from the boundary around it.

Cover: newly generated editorial ink engraving of a terminal chamber beside a locked credential vault and a separate doorway. It is illustrative artwork, not a product screenshot or measured evidence.

Session Isolation: Name the Boundary Before Trusting It

AWS describes dedicated microVMs with separate CPU, memory and filesystem resources for user sessions.^[4] Those are valuable controls against one session reaching another. They do not, by themselves, specify which components inside a single session may inspect each other.

Ask what sits together inside the sandbox, what code receives authority, and which trusted component supplies downstream authentication. A boundary around an application can still contain components with different trust requirements.

AWS's Harness overview combines managed infrastructure with an agent's own shell and filesystem.^[3] That combination is the product's appeal: teams spend less effort building the surrounding machinery. It also makes the diagram of internal authority a necessary part of deployment review, alongside the diagram of cloud tenancy.

Vault Encryption: Storage Protection Has a Defined Scope

AWS documents automatic token-vault encryption at rest with AWS-owned KMS keys, with customer-managed keys available as an alternative.^[10] Our inference: choosing who administers the encryption key is a different decision from choosing which running component can access a usable credential. Evaluate both. A stronger storage policy does not establish separation between a shell and an authentication process.

Default Tools: Every Capability Needs an Owner

The Tools guide says omitting allowedTools permits all tools. It also distinguishes model-selected tools from a separate direct-command API with its own IAM permission.^[2] Restricting the former does not establish that the latter is denied.

Our recommendation is operational: own the effective permission set at the application boundary. Document the capabilities a workflow requires, test that unrelated capabilities are unavailable, and repeat the check when adding an integration. A declared tool list should be a testable contract rather than a reminder in a configuration file.

This introduces a real tradeoff. General-purpose execution is useful precisely because it avoids anticipating every operation. Narrow tools make permitted behavior easier to enumerate. Choose that flexibility deliberately for each workload, and budget for the engineering needed to contain it. The cost belongs in the business case for automation.

Identity: Invocation and Downstream Access Are Separate Decisions

AgentCore Identity manages authentication and credentials for agents accessing AWS and third-party services.^[5] From an application-design perspective, however, an identity service cannot decide which customer record a particular support request should see. That requires the surrounding authorization policy.

AWS's Harness security guide describes user-scoped downstream credentials through inbound OAuth. It says SigV4 callers currently do not receive that per-user propagation.^[6] Teams should therefore verify the actual identity flow instead of assuming every integration inherits the caller's permissions.

AWS documents deterministic policy evaluation for traffic passing through AgentCore Gateway, including rules based on user identity and tool inputs.^[11] That gives teams an enforcement point beyond the model's explanation. Its scope matters: a Gateway policy should not be counted as control over every command executed by a shell. Map the routes that pass through it and the routes that do not.

Shared Responsibility: Turn Documentation Into Acceptance Criteria

AWS's general responsibility model says customer obligations vary with the service and integration.^[7] Its Identity data-protection guidance places security configuration with the customer and recommends activity logging and credential protection.^[8] Those statements explain ownership; they are not independent confirmation of the researchers' reported experiment.

The VPC guide says security groups govern which resources the runtime can communicate with and recommends least-privilege rules plus VPC Flow Logs.^[12] Our synthesis: network reach, tool permission and data authorization are separate acceptance criteria. Verify them with harmless synthetic data, including a disallowed destination and a disallowed business action. Access to an approved service does not mean every operation there should be authorized.

Managed infrastructure makes agent deployment easier. It does not erase the operator's obligation to understand delegated authority. The enterprise advantage will belong to teams that can explain, test and constrain what their agents may actually do.

Last updated: October 5, 2026