It was an accident. It was also a reminder that AWS S3 permissions are both powerful and dangerous. When you deal with open source models stored in S3, you can’t afford to guess at IAM policies. The right configuration isn’t a “nice to have”—it’s the wall between safe distribution and uncontrolled leakage.
Why read-only roles matter for open source models
Open source models—especially large machine learning or AI models—often need to be shared with broad audiences. This means setting up AWS S3 access that allows fast, reliable reads, but no writes, no deletes, and no object modifications. A read-only IAM role ensures that anyone with the role can download or list objects, but not alter them. Without it, you risk both model corruption and exposure to malicious uploads.
The core AWS S3 permissions for a true read-only role
A minimum secure read-only IAM policy for S3 should look like this:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::YOUR_BUCKET_NAME",
"arn:aws:s3:::YOUR_BUCKET_NAME/*"
]
}
]
}
Avoid granting s3:GetObjectVersion or s3:GetBucketAcl unless explicitly required. Reduce the policy scope to the minimum resources needed. Always specify exact bucket ARNs instead of using wildcards unless your architecture demands otherwise.
Key steps for locking it down