Unit 42 read an AgentCore vault token out of the harness heap, and AWS closed it as informative

Two fixes and one refusal

In August 2026 Amazon Web Services published two security bulletins for the same corner of its agent stack, and fixed both.

CVE-2026-18830, bulletin 2026-073, published 4 August: the Amazon Bedrock AgentCore harness could dispatch a tool named directly by the caller, skipping the model and the controls that sit around it. AWS, which is the assigning authority for its own CVEs, scored it 8.6 under CVSS 4.0 and 8.1 under CVSS 3.1. The fix was server side, applied to the managed API before 31 July 2026, and the bulletin says no customer action is required.

CVE-2026-18733, bulletin 2026-072, published 3 August: the shell tool in Strands Agents Tools, the open source framework that powers the AgentCore harness, exposed a parameter the model could set that skipped the human consent gate on command execution. AWS scored it 7.5 under CVSS 4.0 and 8.8 under CVSS 3.1. The fix was version 0.8.0.

On 18 September 2026 Unit 42, the research arm of Palo Alto Networks, published a third finding in the same place. AWS had closed it on 10 June as informative.

That is 100 days between the closure and the publication, and 93 days between the harness reaching general availability on 17 June 2026 and today. In that time the sentence at the heart of the finding has not changed. AWS's own Tools page for the harness, fetched this morning, still reads:

Default tools shell and file_operations are available in every session unless you restrict them with allowedTools.

Two lines later the same page adds: if allowedTools is omitted, all tools are allowed.

What that does not establish. It does not establish that AWS was wrong to close the report, that the finding is more severe than the two AWS fixed, or that AgentCore is less safe than a rival runtime. The three findings differ along an axis that has nothing to do with impact. The two AWS fixed describe the harness doing something its documentation did not say it did. The one AWS closed describes the harness doing, precisely and in public, what its documentation says it does.

That is the interesting part, and it is the part a UK cloud team has to make a decision about. A documented default is not a safe default. It is a default you have been told about.

What an agent harness is, and what it hands the agent

AWS's framing is worth taking at face value, because the research depends on it. In the general availability announcement of 17 June, AWS put it this way: if the model is the brain, the harness is the body. You declare an agent in configuration, naming the model, the tools, the skills and the instructions, and AgentCore assembles and runs the orchestration loop.

What the configuration buys you, in AWS's words on the harness overview page, is a production grade agent running "in minutes in its own isolated environment, with a filesystem and shell". Every session gets its own Firecracker microVM. Sessions last up to eight hours on a microVM, and the default cap on reasoning and action cycles per invocation, maxIterations, is 75.

Two tools come switched on. shell executes bash commands. file_operations views, creates and edits files. They are not opt in, they are opt out, and the opt out is the allowedTools parameter.

AWS gives a second, quieter reason to set it. The two default tool definitions add roughly 900 input tokens to every model request, whether or not the agent ever calls them, and one invocation can make many model requests. At the default cap of 75 cycles that is on the order of 67,500 input tokens per invocation spent describing two tools you may never have wanted. The arithmetic is mine and the AWS page warns that the exact count varies by model, so treat it as an order of magnitude rather than a bill.

There is a third thing worth knowing before the research makes sense. allowedTools scopes the model's tool selection during InvokeHarness only. It has no effect on InvokeAgentRuntimeCommand, the separate API that runs shell commands in a live session without the model in the path at all. AWS states the remedy plainly: to prevent direct command execution, do not grant bedrock-agentcore:InvokeAgentRuntimeCommand in your IAM policies.

What Unit 42 actually demonstrated

Unit 42's researcher, Niv Rabin, built a fictional operator called SupportCo: a customer support agent on AgentCore harness that reads inbound tickets, looks up account records through a downstream Model Context Protocol server, and answers. The MCP server required an Amazon Cognito bearer token. That token was stored in the AgentCore Identity token vault and referenced from the harness configuration by ARN, which is the pattern AWS documents.

The chain that followed has five steps, and the honest version includes what had to be true for each.

Reconstructed from Unit 42's account of its own test rig. The right column is the article's reading of what each step required.

Step	What Unit 42 did	What it needed to be true
1	Landed an instruction in a hidden HTML comment inside a support ticket, telling the agent to fetch a script and pipe it to python3	The agent processes content the operator does not control, and the harness has network egress
2	Got the shell tool to run it	The shell tool was in scope. Unit 42 reports the well aligned model refused twice, so they selected a more permissive model per invocation
3	Ran whoami and id, and read the process list from the proc filesystem	Root inside the microVM. Unit 42 reports the shell subprocess ran as root, a direct child of process 1
4	Read process 1's memory and scanned it for a token pattern and the MCP server URL	Process 1 was the harness runtime, the same UID on both sides, and its memory readable
5	Posted a 1,034 byte token and the MCP URL to an external webhook, then replayed them	Outbound HTTP to an endpoint that was not a configured integration

Step 2 deserves more weight than the coverage gives it. Unit 42 says the capable model refused the direct request twice. What made the chain work was not beating a model's judgement, it was choosing a different model, which the harness allows per invocation. AWS documents that as a customer risk in its own security page: callers who can set the model fields can redirect inference to a different model, region or provider entirely.

So the precondition is real, and it cuts both ways. It is a genuine caveat on the demonstration. It is also a configuration surface AWS hands to the caller by design, and one most operators have not thought about.

Whose identity was that, and why it was that one

The question that matters for a cloud team is not how the token left. It is why that token was there at all.

Unit 42's answer is the clearest part of the research. An end user's session token cannot live in a vault: it is minted at login, expires quickly, and belongs to whoever happens to be signed in. You cannot pre enrol it, and you cannot stand up a harness per user to hold it. So what goes into the vault is the stable credential, the operator's service account, wired in once and reused across every session.

AWS documents the consequence from the other direction. On the harness security page it notes that when callers authenticate with SigV4, the harness does not propagate per user identity into downstream tool calls, so the per user features of AgentCore Identity, including user scoped token storage and on behalf of exchange, are available only when callers authenticate with a bearer JWT through the inbound OAuth path. SigV4 support for per user identity is described as planned for a future release.

Put those two statements side by side and the shape is clear. A caller authorised to do one thing, invoke the harness, reaches a runtime that acts as something with far broader authority. AWS's own credentials guidance names the failure mode directly, advising operators to avoid privilege escalation by ensuring the execution role has equal or fewer privileges than the users who can invoke it.

That is good advice, and it is quietly hard to follow. The reason an operator reaches for an agent is usually that it should be able to do things the caller cannot.

Stated and not stated in AWS's documentation

Everything in the left column below is a sentence I fetched from AWS's developer guide today. Everything in the right column is something the same documentation does not say, checked across the harness overview, tools, environment, security, sessions, credentials and runtime best practice pages.

Left column quoted or closely paraphrased from the AWS Bedrock AgentCore developer guide, accessed 18 September 2026. Right column: absent from the same pages on that date.

Stated by AWS	Not stated by AWS
The shell and file_operations tools are available in every session unless allowedTools restricts them, and if allowedTools is omitted, all tools are allowed	That the model invoked shell tool runs as root in the same process user as the harness runtime
Commands have full access to the container filesystem and any configured credentials or secrets within the microVM, and the isolation boundary is the microVM itself	That a vault credential resolved for use remains in that process's heap in plaintext, readable through the proc filesystem
MMDS provides execution role credentials to any code or actor running inside the VM, similar to EC2 instance metadata	Whether a resolved vault credential is cleared from memory after the downstream call completes
Input validation and prompt injection prevention are the customer's responsibility, including validating InvokeHarness input	Any change to the default availability of the shell tool since the report was closed on 10 June 2026
Commands run as root, uid 0, within the microVM, and a USER directive in your Dockerfile applies only to the agent process	Any CVE, bulletin or advisory covering this finding, unlike CVE-2026-18830 and CVE-2026-18733

Two of those left column entries are worth reading twice. AWS states, in its runtime security best practices, that commands reach any credentials inside the microVM and that the microVM is the boundary. It also states, in its credentials page, that any code or actor inside the VM can retrieve the execution role's temporary credentials from the metadata service.

Unit 42 did not use the metadata path. It did not need to. But a defender should note that the documented capability is broader than the demonstration: the metadata route reaches AWS IAM credentials, scoped to whatever the execution role allows, and it is a documented property of the platform rather than a finding. That is an inference about reachability from AWS's own text, not something Unit 42 showed.

A vault is a word about storage

AgentCore Identity's terminology page defines the token vault as secure storage for OAuth tokens and API keys that "ensures credentials can only be accessed by the specific agent and user combination that originally obtained them". The data encryption page adds that vault contents are encrypted at rest with AWS owned keys by default, or with a customer managed KMS key, and in transit throughout.

Every one of those statements is true, and none of them is about the moment that mattered. Access control on the vault governs who may ask the vault for a credential. Encryption at rest governs the bytes on disk. Encryption in transit governs the bytes on the wire. The heap is none of those places.

Unit 42's own summary is the shortest version: vaults protect at rest and in transit, not in use.

Why AWS closed it, and whether that holds

AWS's position, as Unit 42 reports it, is that the finding falls under the AgentCore shared responsibility model, and that the customer side controls are allowedTools scoping and egress filtering. AWS's own harness security page sets out the same split. On the AWS side: infrastructure and microVM isolation at hardware level, kernel patching, the managed harness runtime code including validation of the request structure InvokeHarness accepts, and network infrastructure. On the customer side, among others: IAM access controls, security of commands executed in runtime sessions, input validation and prompt injection prevention, model configuration validation, and network configuration.

Read against that list, the closure is internally consistent. Two of the customer's named responsibilities are exactly the two links in the chain.

Compiled from the two AWS security bulletins, the corresponding NVD records and Unit 42's disclosure timeline. Scores are AWS's own, as the assigning authority; CISA added a decision record to both NVD entries but no score.

Finding	AWS treatment	Why the treatment differs
CVE-2026-18830, harness dispatched a caller named tool without the model	Fixed server side before 31 July 2026, CVSS 4.0 8.6, no customer action	The harness accepted a request shape it had never said it would honour
CVE-2026-18733, shell consent gate bypassed by a model set parameter	Fixed in Strands Agents Tools 0.8.0, CVSS 4.0 7.5	A documented safeguard did not hold
Unit 42 heap read of a resolved vault token	Closed as informative on 10 June 2026, no CVE, no bulletin	Every step is documented behaviour operating as described

Where the closure gets uncomfortable is the marketing. The general availability announcement says that identity, memory and observability come from the same platform, "so every agent action is governed and traced from the first call without additional wiring". Tracing is real: the harness operations page confirms that model calls, tool invocations, memory operations and shell commands each appear in CloudWatch traces with timing and payload detail, from the first invocation and with no extra configuration, though you do need Transaction Search enabled in CloudWatch once per account.

Governed is doing more work. A trace of a shell command that read process memory is a record, not a control. The control that would have stopped it, allowedTools, ships in the permissive position, and the operator has to know to set it on the invoke call rather than at creation.

There is a second asymmetry worth naming. AWS advises, in runtime security best practices, that you run containers as non root when you build custom images, and notes on the environment page that a USER directive in your Dockerfile applies only to the agent process. The managed harness image is AWS's, not yours. Unit 42 reports that the shell subprocess and the runtime shared root and the same user id. On the evidence available, non root is advice a customer can follow for their own container and cannot apply to the managed one. AWS's documentation does not state the managed harness image's user, so this rests on Unit 42's observation of one deployment.

Unit 42's interest, stated plainly

Unit 42 is Palo Alto Networks. The research closes by recommending Cortex Cloud and the Unit 42 Cloud Security Assessment, and links its incident response line. That is a commercial position and it should be visible when you read the recommendations.

It does not touch the findings. The method is reproducible from the description, the disclosure went through AWS's HackerOne programme with a report number and a merge into an earlier report, and the three operator recommendations it ends on name AWS parameters rather than Palo Alto products: scope allowedTools, scope vault service accounts to least privilege, and watch outbound traffic from harness containers. Two of those are AWS's own documented controls. The third is generic network monitoring.

Take the evidence at full weight and the product conclusions at whatever weight you would give any vendor's.

Three questions for a UK cloud team

We covered a related pair of findings on 16 September: browser extensions commanding built in AI agents through pages those agents were built to obey, and Mandiant's case study of an attacker hijacking a live AI coding session. The lesson there was that the channel is the privilege. Mandiant's controls in that report, and ours, came down to keeping long lived tokens out of reach of the assistant's session and controlling what an assistant session can reach on the network.

This is the managed cloud version of the same sentence, and it converts into three questions you can put to any agent deployment.

The three questions, with where AgentCore's answer is written down.

Question	AgentCore's answer today	Where AWS states it
Which identity does the agent act as?	The execution role for AWS calls, and the vault service account for downstream tools. Not the caller, unless inbound OAuth is configured	Harness security page, SigV4 and per user identity note
What can that identity reach?	Every downstream service the operator wired in, plus whatever the execution role allows through the metadata service	Credentials management page and the execution role policy
Can a sentence move it?	Yes, while the shell tool is in scope and the session has egress	Tools page defaults, and the customer side of the shared responsibility split

If you cannot answer the first question for an agent already in production, that is the finding, and it does not require anyone's research to reach you.

What to do

The question that exposes the gap

AWS is right that this is shared responsibility, and the documentation does say what it does. The awkwardness is that the sentence which carries all the weight, "available in every session unless you restrict them", is a sentence about a default, and the people reading it are configuring an agent, not conducting a threat model. The two AgentCore issues AWS did fix in August are both cases where the product surprised its own documentation. This one is a case where the documentation surprised its readers.

An agent runtime is now an identity boundary whether or not anyone designed it as one. The vault, the microVM and the IAM gate are all real controls, and each of them protects a different thing from the one that failed.

So the question to put to any team running an agent in production, in AWS or anywhere else, is not whether the model can be tricked. Assume it can. It is this: name the identity your agent's downstream calls are made under, list everything that identity can reach, and show what stops a sentence in an inbound support ticket from using it.