Store, measured at rest
AWS Bedrock AgentCore Memory, event plane
edits through the data-plane API
AWS Bedrock AgentCore Memory, event plane was seeded through its own API and edited behind its back nine ways. 3 edits served as genuine, 0 reported on audit, 0 rejected on read, 6 not applicable.
- Measured on
- AWS Bedrock AgentCore Memory (events), boto3, us-east-1
- Date
- Source
- docs.aws.amazon.com/bedrock-agentcore
- Attack versions
- tamper@v1, truncate@v1, delete_middle@v1, reorder@v1, forge@v1, cross_replay@v1, rollback_replay@v1, metadata_tamper@v1, snapshot_rollback@v1
What this means
There is no disk to edit here, so the attacker is a principal holding the data-plane permissions outside the agent's own session. What he can do, he does without a trace: delete any turn from the agent's history, and plant a new one at any point in time, because the event timestamp is set by the caller rather than the service. The agent's next ListEvents serves what is left as its own record, with no error and nothing on the read path that notices. What he cannot do is rewrite a turn that is already there, because the API has no update call at all, and that is a stronger position than a store whose records can be patched. Six of the nine edits are not applicable for that reason, and each says so in its own words rather than sitting blank. CloudTrail records the calls at the platform layer, outside the store, and the read path never consults it.
The 9 verdicts
Detection point: the read path. 0 of the nine edits were refused there, 3 served as genuine, 6 not applicable.
Level L0. What L0 means.
| Edit | Verdict | What the tool said |
|---|---|---|
| T1 Content tamper | n/a | not applicable: AgentCore has no UpdateEvent, so an event's content cannot be changed in place; delete plus create yields a different eventId, which is a different edit |
| T2 Tail truncation | accepted | accepted silently |
| T3 Middle deletion | accepted | accepted silently |
| T4 Reordering | n/a | not applicable: events are ordered by eventTimestamp, fixed at creation, so an existing event cannot be moved to another position |
| T5 Forged insertion | accepted | accepted silently |
| T6 Cross-context replay | n/a | not applicable: AgentCore has no UpdateEvent, so an event's content cannot be changed in place; delete plus create yields a different eventId, which is a different edit |
| T7 Rollback replay | n/a | not applicable: AgentCore has no UpdateEvent, so an event's content cannot be changed in place; delete plus create yields a different eventId, which is a different edit |
| T8 Metadata tamper | n/a | not applicable: an event's actor, session, timestamp and id are fixed at creation and the API exposes no way to change them |
| T9 Snapshot rollback | n/a | not applicable: a managed store exposes no snapshot or restore of its own state |
Where the attacker stands
The attacker holds the AgentCore data-plane permissions for this memory, outside the agent's session: a leaked access key, a second workload in the same account, or a platform operator. He does not hold the agent's own session, and he does not need it.
Reproduce this row
Everything runs offline unless the store is a managed cloud service, in which case the row needs a project of your own. The run seeds a fresh store, applies each edit, confirms it landed, reopens the store and records what came back.
pip install 'agent-memory-integrity[bedrock]'
export AGMI_BEDROCK=1 AWS_DEFAULT_REGION=us-east-1 # plus AWS credentials
python agmi/full_runner.py --json results/scorecard.json # every row, this one included
python -m agmi.agent --target bedrock-agentcore-events --families at-restBadge
Maintainers can link their row from their README. The badge points here and changes nothing on your side:
[](https://agentmemoryintegrity.org/stores/bedrock-agentcore-events.html)