The vault is not the boundary: agent runtimes hold credentials in clear

What was reported

On 18 September 2026 Unit 42 researcher Niv Rabin published an analysis of AWS Bedrock AgentCore, describing a gap between where credentials are protected and where they are used ^[1]. AgentCore Identity holds credentials in a vault, encrypted at rest and in transit under KMS keys with IAM controls, and AWS documents the service as verifying each request independently with no implicit trust based on source ^[1][2]. That property is about requests. It is not a property of the process that consumes the credential.

Rabin's account is that at the moment of use the harness resolves a vaulted credential into plaintext inside its own process, while the built-in shell tool — enabled by default — executes as root in that same process context ^[1]. Instructions hidden in content the agent was asked to read, in the demonstrated case a support ticket, could reach that tool, and from there the operator's service-account token became recoverable and replayable against downstream services ^[1]. The researchers used a recovered bearer token to query a downstream MCP server holding personal data ^[1]. The credential at risk belonged to the operator's service account rather than the end user, which widens rather than narrows the consequence.

The disclosure went to AWS through HackerOne on 19 May 2026 ^[1]. AWS reviewed it and closed it as informative under the AgentCore shared responsibility model, identifying the customer-side controls — scoping the allowedTools parameter at invocation and filtering egress — as the mitigations ^[1]. No CVE was assigned and no advisory was published ^[1].

Why the vendor's answer is the story

Read narrowly, this is a configuration argument between a researcher and a platform team. Read as an operator, it is worse than a vulnerability. A CVE enters a scanner, a ticket queue and a patch window. Documented default behaviour enters none of those. Every organisation running agents on this pattern carries the exposure until somebody reads the configuration and changes it, and nothing in the standard vulnerability management cycle will prompt that review.

The architecture error is not specific to one vendor. It is the assumption that a secrets vault establishes a boundary, when what a vault establishes is protection at rest and in transit. The boundary is wherever the credential exists in usable form, and in an agent runtime that is a process shared with tools chosen for their breadth. Unit 42 made the general version of this point in May 2025, finding that the vulnerabilities in agentic applications were largely framework-agnostic and arose from insecure design patterns, misconfigurations and unsafe tool integrations rather than from flaws in the frameworks themselves; service account token exfiltration was one of nine scenarios demonstrated across two frameworks ^[3].

Injection is not hypothetical

The delivery half of this is in the wild. Unit 42 documented web-based indirect prompt injection in March 2026, finding hidden instructions planted in ordinary web content for agents to ingest ^[4]. Of the injected pages observed, 75.8% carried a single injected prompt and the rest carried several; the leading attacker intents recorded were producing irrelevant output at 28.6%, data destruction at 14.2% and content moderation bypass at 9.5% ^[4]. Those intents are mostly unsophisticated, which is the point: the delivery mechanism works, and the payload is a matter of who is using it.

The UK NCSC's position, published in 2023 and not yet overtaken, is that there are no failsafe measures that remove prompt injection risk, and that the system around the model rather than the model itself must carry the security properties ^[5]. OWASP reaches the same conclusion in LLM01:2025, listing privilege control, human approval for high-risk actions and segregation of external content ahead of any filtering measure ^[6]. NIST's adversarial machine learning taxonomy, AI 100-2 E2025, provides the shared vocabulary for classifying these attacks ^[7].

The wider credential picture

Credential handling across the agent tool ecosystem is in worse condition than the AgentCore case alone suggests. OWASP's MCP01:2025 entry names contextual secret leakage directly: tokens persisting in model memory, logs and protocol layers, extractable through prompt manipulation or log access, with hard-coded credentials, long token lifetimes and shared service accounts as the detection indicators ^[8].

The Cloud Security Alliance's AI Safety Initiative measured the consequence. Its 29 June 2026 research note records 24,008 unique secrets exposed in MCP configuration files on public GitHub, of which 8.8% were confirmed still valid at scan time, alongside CVE-2026-12957 (CVSS 8.5) and CVE-2026-12958 in Amazon Q Developer and CVE-2025-59536 (CVSS 8.7) and CVE-2026-21852 (CVSS 5.3) in Claude Code, arising from repository-embedded configurations initialised at project open before trust verification ^[9]. A companion note from 1 July 2026 reports the MCPTox benchmark measuring a 36.5% average tool-poisoning success rate across models with a peak of 72.8%, and records a worm campaign that planted malicious MCP configurations across 73 repositories ^[10].

Exposure is also growing on the server side. TrendAI researchers Alfredo Oliveira and David Fiser found 1,467 exposed MCP servers in April 2026, against 492 in July 2025 — roughly a tripling in nine months ^[11]. Among them, SQL execution tooling on 70 hosts, agent memory implementations on 39 hosts, at least three servers reachable to clinical record functions, and 1,227 servers still running a deprecated transport ^[11]. Two CVSS 9.8 issues in AWS and Azure MCP implementations, CVE-2026-5058 and CVE-2026-5059, were disclosed through the Zero Day Initiative ^[11].

What to do

• Scope tools at invocation. Pass an explicit allowedTools list and leave shell and file operations out of it unless a specific task needs them ^[1].
• Give the agent's vault-backed service account the minimum permission its single downstream integration requires, and a separate identity per integration ^[1][8].
• Treat the agent's identity as having a blast radius. Ask what a replayed token from that account reaches, and reduce that answer before hardening prompts ^[1].
• Monitor egress from agent containers as a security control, not as an availability metric. It is the detection of last resort when the credential has already been read ^[1].
• Inventory MCP servers and treat repository-embedded MCP configuration as code requiring review, not as project metadata ^[9][10].
• Rotate credentials used by developers running affected AI coding assistant versions, and prefer short-lived SSO-issued credentials over stored long-lived keys ^[9].
• Take exposed MCP servers off the public internet and check what tooling each one publishes before deciding it is low risk ^[11].

The domain point

Offensive testing of agent deployments should not be scoped as a model evaluation. The interesting question is not whether the model can be talked into misbehaving — it can — but what the agent's runtime identity can reach once it has been. That is an identity and privilege assessment with a natural language delivery channel bolted to the front of it, and it belongs to the same team that reviews service account scope and lateral movement. Organisations building agent platforms in the region are largely standing them up on managed cloud services where the defaults were set for convenience. The defaults are where the assessment starts.