A prompt in a support ticket led to a vaulted credential in process memory. The vault did its job. The credential still left in one HTTP POST, and it belonged to a service account.
Entry point. support ticket, instructions hidden in HTML comments.
The identity in the middle. The operator service account whose JWT the agent runtime held, plus the MCP URL beside it.
What was reached. customer data, replayed from outside AWS.
A prompt in a support ticket led to a vaulted credential in process memory.
Taken from the published reporting. Nothing here is reconstructed.
| Step | Role in the path | What the reporting records |
|---|---|---|
| support ticket | Entry | instructions hidden in HTML comments |
| agent | Step | accepts the tool call, runs a command |
| shell tool | Step | on by default, root in the harness |
| process heap | Step | /proc/1/mem, scanned for JWT patterns |
| service jwt | Step | vaulted credential, plus the MCP URL |
| customer data | Reached | replayed from outside AWS |
The shell tool that was on by default in the harness. The vault held: the credential was only reachable because the agent could run a command and read /proc/1/mem. Taking default shell access away closes the path before the token is ever in reach.
A breakpoint is the single change that closes a path with the least disruption. Read how that is chosen in the breakpoint page. The full narrative is in the teardown.
6 steps from entry to data.
Every field on this page is taken from the published reporting below. The breakpoint assessment is Elmoz reading that path, not a statement about what the affected organisation did.
Unit 42, Palo Alto Networks · CloudTech News · Cybernews · AWS AgentCore Identity documentation
The two questions this record answers.
The published path starts at support ticket, instructions hidden in HTML comments.
The last step in the published path is customer data, replayed from outside AWS.
Same database, different path shape.
Book a demo and we walk through the access paths in an environment like yours.