AgentCore and S3 Files: What AWS Says About Shared File Systems for Document-Investigation Agents

AWS published a reference design on October 27 for a document-investigation agent: a Lambda function stages a case folder onto an Amazon S3 Files file system, and an Amazon Bedrock AgentCore runtime agent mounts the same file system and investigates it with ordinary file reads and writes. The post's most useful parts are not the CloudFormation. They are its three consistency rules and its list of prompt injection controls.

I read the whole AWS post. I did not read the S3 Files documentation, the AgentCore file system guide or the Serverless Land sample it links, and I did not deploy anything. This is what the post says, plus my own suggestions where I label them.

The design as described

The post says the problem is investigations where you do not know in advance which files you need. Its example is a contract dispute, where the agreement points to an addendum and the addendum points to an invoice. The usual alternative it names is chaining stages through object downloads and uploads, which adds orchestration, payload size limits and serialization code.

Per the post:

• S3 Files presents an S3 bucket as a shared file system over NFS, with read-after-write consistency, file locking and POSIX permissions.
• A Lambda function can mount it directly. AgentCore runtime can mount an S3 Files access point into every agent session at a path you choose, through bring-your-own file system support.
• Stage 1 is a Lambda function that normalizes a document set into one case folder and writes a manifest.json.
• Stage 2 is an agent on AgentCore runtime that reads the manifest, lists the folder, opens documents, follows references and writes structured findings back.
• The S3 bucket stays the source of truth, and changes on the mount synchronize to it.

The sample is a single CloudFormation template using AWS::S3Files::* resource types, plus AWS::Lambda::Function and AWS::BedrockAgentCore::Runtime. Details the post states: the Lambda mount path must be under /mnt/ with one subdirectory level, the function needs at least 512 MB of memory, the agent attaches the access point through FilesystemConfigurations.S3FilesAccessPoint, and security groups allow NFS on port 2049 to the mount targets. IAM permissions named are s3files:ClientMount and s3files:ClientWrite scoped to the access point ARN, s3:GetObject for direct reads, and bedrock:InvokeModel for the agent.

The three consistency rules

This is the part I would keep even if you never use these services together.

1. Read from the mount. The post says reads on the mount are immediate, while the sync back to S3 is asynchronous. It says reading the bucket copy instead can return stale or missing data until the export catches up, and points to the PendingExports CloudWatch metric.

2. One writer per path. If a file on the mount and its S3 object change at the same time, the post says S3 Files treats the bucket as the source of truth and moves the file to a lost-and-found directory. In the sample, Lambda owns raw/ and the manifest, and the agent owns findings/.

3. Name files per producer. Each output gets its own path instead of appending to a shared file.

The prompt injection section

The post treats every file on the shared file system as untrusted input. It names three failure shapes:

• Skewed findings. A planted line such as a note claiming an internal audit cleared a vendor shows up as a conclusion.
• Crossing case boundaries. If a tool takes a case ID or path from the model, injected text can steer the agent into another case's folder. The post says IAM and POSIX permissions do not prevent this when all cases share one access point.
• Persistence. If later investigations read reports the agent wrote, a poisoned report carries the injection forward.

Its controls, strongest to weakest as the post orders them:

1. Take the case ID from the invocation payload, not the model. Resolve paths to canonical form and refuse anything outside the case folder. For separation below the application, use one access point or session-scoped credentials per case.

2. Keep the write path separate from the intake path, so the agent cannot change raw documents.

3. Require evidence for every finding: source file and passage, with review before anyone acts.

4. Screen document text with Amazon Bedrock Guardrails inside the tool. The post says a guardrail attached to the Converse call does not evaluate tool results, so it recommends calling ApplyGuardrail from the read tool with source INPUT and the prompt attack filter set to block, and with source OUTPUT on findings before writing.

5. Log every path opened or refused, per case, and alert on unexpected reads, refusals and guardrail blocks.

One thing worth noticing: the sample's read_document tool, as shown in the post, takes a case_id and a relative path as arguments. The post's own first control says the case ID should come from the invocation payload, not the model. The snippet is labeled as an example of a tool, not as the hardened version, so read the two together.

Versus Bedrock Data Automation

The post says Data Automation extracts structured output from documents, images, audio and video through a managed pipeline, which fits when you know the documents and fields in advance. A custom agent fits open-ended investigations where one document points to another. It also says running your own agent gives control over the reasoning loop, retries and output shape.

What I would check

These are my untested suggestions.

1. Quotas and regions. The post tells you to check current Service Quotas for S3 Files before scaling. Do that, and confirm where AgentCore and S3 Files are both available for you.

2. Per-case isolation. If you handle documents from different customers, decide up front whether one access point per case is worth the overhead. The post lists it as the strongest control.

3. Your read tool's signature. Check whether the model can choose a path or case ID, and test a path traversal attempt.

4. Lost-and-found behavior. The post says to test how your workload behaves when a file is moved there. Do it before production.

5. Alerting on PendingExports. Only matters if something reads the bucket directly, but then it matters a lot.

6. Cost. The post gives no pricing. Read the S3 Files and AgentCore pricing pages before you commit.

What I would not conclude

• That this is the right fit for your workload. The post is one reference design.
• That the guardrail step stops injection. The post lists it fourth of five, as a weaker control.
• That the sample is production ready. The post has a "moving to production" section that lists work still to do.
• That the performance or cost is good. The post shares no numbers on either.

Frequently asked questions

What is Amazon S3 Files?

Per the post, it presents an S3 bucket as a shared file system over NFS with read-after-write consistency, file locking and POSIX permissions.

Can AgentCore mount it?

The post says AgentCore runtime can mount an S3 Files access point into every agent session through bring-your-own file system support.

Why not just use S3 APIs?

The post says object downloads and uploads between stages add orchestration overhead, payload size limits and serialization code. It does not benchmark the alternative.

What happens when two writers touch the same file?

Per the post, if a file on the mount and its S3 object are modified at the same time, S3 Files treats the bucket as the source of truth and moves the file to a lost-and-found directory.

How does it handle prompt injection?

It lists five controls: case ID from the payload, separate write path, evidence for every finding, ApplyGuardrail inside the read tool, and per-case logging with alerts.

Is there a deployable sample?

The post says there is a reference implementation on Serverless Land. I did not read it.

Does the post give cost numbers?

No. It says to delete the CloudFormation stack to avoid ongoing charges, and that the S3 bucket and file system are retained by default and need separate deletion.

Sources

All read on October 28, 2026.

• Building document-investigation agents with Amazon Bedrock AgentCore and Amazon S3 Files (AWS Compute Blog, October 27, 2026): the design, consistency rules, security controls.

Not read: the S3 Files documentation, the AgentCore file system configuration guide, the Serverless Land sample, and pricing pages.