What happened
On September 18, 2026, Unit 42 published a controlled test of credential exposure through Amazon Bedrock AgentCore Harness. Amazon Bedrock AgentCore Harness was the tested framework. Unit 42 selected a more permissive tool-calling model and tested a default-configuration harness with shell and an authenticated Model Context Protocol integration. The cited sources do not identify the model or version used in the successful test.
AWS documentation states that default tools shell and file_operations are available in every session unless allowedTools restricts them; omitting allowedTools allows all tools. Unit 42 found the harness shell ran as root, and /proc/1/mem was readable from the shell process. That placed command execution and plaintext credentials resolved for downstream integrations within the same runtime trust boundary.
The runtime executed an indirect prompt injection that fetched a reconnaissance script, piped it into python3, ran the shell as root and read /proc/1/mem. AWS closed the disclosure as informative under its shared-responsibility model and pointed to allowedTools scoping and egress filtering as customer controls. No threat campaign, victim organisation, affected-version range or named model was identified in the cited sources.
Attribution posture: No threat actor or active campaign was identified because the published evidence describes a controlled security test. The finding proves a configuration and runtime pathway under the tested conditions; it does not prove that every AgentCore deployment is exposed, that every model follows the injected instruction or that credentials have been stolen from a production customer. The cited source did not publish the underlying model detail described as Unpublished campaign, version and model information.
Why this matters now
The research moves prompt injection from an output-quality problem to a privileged-runtime problem. When an agent can invoke a root shell in the same environment where downstream credentials become plaintext, successful manipulation can inherit operating-system, network and identity reach that ordinary model guardrails were never designed to contain.
AWS documentation confirms that omitting allowedTools permits all tools, including default shell and file_operations capabilities. That makes configuration review a concrete Monday task rather than a theoretical discussion about model behaviour. Security teams can identify the exposed control state without waiting for a CVE, model update or confirmed campaign.
The disclosure also sharpens shared-responsibility boundaries. AWS treated the report as informative and identified customer-side controls, so enterprise risk acceptance belongs with the operator. AI platform owners need explicit approval for command execution, credential retrieval and outbound connectivity rather than assuming the managed harness supplies least privilege automatically.
The decision for security leaders
Pause production approval for harnesses whose tool, identity and egress boundaries cannot be demonstrated. This is an authority-governance issue, not a request for another generic prompt filter.
Require AI platform owners to document the model, tools, credential providers, downstream services, runtime privilege and emergency-disable path for each production agent. Security should approve exceptions rather than inherit them after deployment.
Treat AWS’s shared-responsibility response as a clear ownership signal. The enterprise must deliberately restrict allowedTools, credential scope and egress, then test whether untrusted content can influence command execution.
Evidence of closure
- Agent inventory records allowedTools, runtime privilege, identities and egress destinations.
- Production harnesses reject tested indirect prompt-injection command paths.
- Credential providers expose only approved task-specific permissions.
- Telemetry captures agent tool calls, shell commands, secret reads and outbound connections.
The Security.io assessment
The research is persuasive because it surfaces a mechanical path: injected content influenced a tool-capable model, the managed runtime executed a command, and the command inherited root-level access to process memory containing resolved credentials. The risk does not depend on claims about model intelligence or autonomy.
The evidence is a controlled test rather than an observed campaign, so incident-response escalation is not justified without matching telemetry. Configuration remediation is justified now because AWS documentation confirms the permissive tool behaviour and the mitigations are under customer control.
Unit 42 found the harness shell ran as root, and /proc/1/mem was readable from the shell process. AWS closed the disclosure as informative under its shared-responsibility model and pointed to allowedTools scoping and egress filtering as customer controls. No threat campaign, victim organisation, affected-version range or named model was identified in the cited sources.
Questions for the morning meeting
- Which production AgentCore sessions omit allowedTools or permit shell access?
- Can any agent identity retrieve credentials broader than its immediate task requires?
- Do harness containers have enforced egress destinations and complete command telemetry?
- Who can disable an agent identity without waiting for the application owner?