AgentCore: validate where each session’s files can go
The runtime needs a map of the data it can reach. Compare permissions, persistence and recovery before expanding an agent.
Читать на португальскомBy Pentesty
Separate the announcement from configuration
On November 12, AWS announced larger sessions and dynamic mounts in AgentCore Runtime. The announcement itself presents automatic session-to-folder binding through labeled credentials as a step planned for re:Invent. That forecast does not establish that every current mount already has automatic separation by session.
The documentation distinguishes managed session storage from customer-owned S3 Files or EFS systems, which can be shared. It also describes persistence and permissions for each option. The selected configuration should determine the assessment plan; an isolated execution environment alone does not establish who can access every shared file or how the organization should approve that access.
Map the task’s data paths
Choose a small task, such as generating a report from artificial files. List each input source, the working directory and the result destination. Identify who should be able to resume the work and who should receive only the final report. Record the application version and configuration identifier used for the exercise so that another person can repeat it.
Separate material serving several tasks from content reserved for one execution. Use different artificial identifiers for two test users and include the association between each user and session in the approved plan. Add an allowed operation and an attempt that should be denied to the matrix. The data owner should accept these expectations before the assessment starts.
Check access with two sessions
Run the approved task in the first session and write a harmless marker at the agreed location. In the second session, attempt only the reads and writes defined in the plan. Observe the storage service outcome as well as the agent response. A message claiming access failed should correspond to the actual decision of the resource receiving the request.
Where both sessions should share an input, assess reading separately from permission to change it. Where a result belongs only to the first task, check that boundary using a disposable file without real data. Preserve session identifiers, the applied policy and each operation’s outcome. Record any permission change introduced to make the pilot work before accepting its results.
Treat resumption as another decision
Agree which files should survive an interruption and for how long. Stop execution through the authorized procedure, confirm that it has stopped and resume only the planned scenario. Compare the recovered content with the expected markers. Include an application update in a disposable environment, because acceptance should also address version changes rather than assuming the same behavior continues indefinitely.
Include permanent task completion as well. Identify who decides to retain a result, which procedure removes temporary material and what evidence confirms removal at the destination. Retention policy should cover intermediate files and copies created by the workflow itself. Shutting down the test environment does not automatically end the organization’s responsibility for those records and their permitted audience.
Frequently asked questions
What is the first exercise artifact?
Start with the map linking user, session, directory and permitted operation. Then record a test attempt’s outcome at the storage resource itself.
How can sensitive data be avoided?
Use artificial files with different markers for each task. They should reveal a read or modification without exposing customer information.
What should be checked during resumption?
Compare recovered files with the plan’s expected result. Record the configuration and check that the person resuming the task remains authorized to access it.
When should the assessment be repeated?
Repeat after material changes to versions, policies, directories or integrations. Keep the previous matrix so that the owner can identify the effect of the change.
Sources and references
Original Pentesty analysis, published November 12, 2026. The proposed scenarios are editorial guidance, with scope and validation to be defined for each environment.