Goal

The langchain-mongodb-deepagents-vfs package has a real-service E2E suite (tests/e2e_tests/test_real_e2e.py, test_watcher_e2e.py) that needs a real S3 bucket. The bucket langchain-mongodb-deepagents-vfs already exists in account 857654397073 and drivers-test-secrets-role can already read and write objects in it. The suite cannot run because the role has no s3:ListBucket permission on any bucket. Adding that one action unblocks the suite.

Blocked by

Nothing.

Current state (verified 2026-08-31 via awscli as arn:aws:sts::857654397073:assumed-role/drivers-test-secrets-role)

S3 action	Status
s3:PutObject	works
s3:GetObject	works
s3:DeleteObject	works
s3:HeadObject	works
s3:ListAllMyBuckets	works (list-buckets succeeds)
s3:ListBucket	AccessDenied - "no identity-based policy allows the s3:ListBucket action"
HeadBucket	403 Forbidden - authorized as s3:ListBucket, so fails for the same reason

The s3:ListBucket denial is role-wide, not specific to this bucket: it also fails on pymongo-voyageai and pymongo-release-assets.

The ask

Add to the identity policy for arn:aws:iam::857654397073:role/drivers-test-secrets-role:

{
  "Effect": "Allow",
  "Action": "s3:ListBucket",
  "Resource": "arn:aws:s3:::langchain-mongodb-deepagents-vfs"
}

No bucket policy change, no new bucket, no object-level changes needed.

Prerequisites not obvious from the ask

• Do not scope this with an s3:prefix Condition. Restricting s3:ListBucket to the test prefix looks tighter, but HeadBucket is authorized as s3:ListBucket with no prefix key in the request context, so a StringLike: s3:prefix condition would deny it. The backend calls head_bucket in its constructor (langchain_mongodb_deepagents_vfs/backends/s3.py:76), so a prefix-scoped grant leaves the suite exactly as broken as it is today, with a confusingly different error.
• The suite confines all writes to the prefix langchain_mongodb_deepagents_vfs_e2e_test/ and deletes them on teardown, so unscoped ListBucket on this one bucket is the intended blast radius.

Why the two failures both trace to this

• backends/s3.py:76 - _verify_bucket() calls head_bucket in the S3 adapter constructor. A 403 is not 404/NoSuchBucket, so it raises AdapterError(E2002_OBJECT_READ_FAILED) and kills backend construction before any test body runs.
• backends/s3.py:236 - list_keys() paginates list_objects_v2 to discover seeded files during the initial sync; without ListBucket it raises E2005_LIST_FAILED. The test teardown uses the same paginator.

Acceptance criteria

• aws s3api list-objects-v2 --bucket langchain-mongodb-deepagents-vfs --prefix langchain_mongodb_deepagents_vfs_e2e_test/ succeeds as drivers-test-secrets-role.
• aws s3api head-bucket --bucket langchain-mongodb-deepagents-vfs returns success (not 403).
• pytest tests/e2e_tests/test_real_e2e.py passes against the real bucket.

Notes

• Object-level permissions are already correct - this ticket is purely the one bucket-level action.
• s3:GetBucketLocation is also denied, but no code path calls it; it is not part of this ask.
• Until this lands, the suite can only be run against a local MinIO stand-in, which does not exercise real S3 behaviour.