Owner security checklist

Work through this when you set quickS3 up, and come back to it every few months.

Connections

• Each connection uses a key made only for quickS3, limited to the buckets your team needs. (How)
• Bucket scopes list the buckets people should see, if the key can reach more.
• Backend upload fallback is off. If you had to turn it on, you have a plan to fix CORS and turn it off again.
• Versioning or backups are switched on at your provider for anything you can’t afford to lose. quickS3 has no recycle bin.

People and roles

• Two Owners, so the organisation doesn’t depend on one person. No more than you need, since Owners can reach everything.
• Admins who need files have a custom role. Admin alone doesn’t give file access.
• Roles are named after jobs, not people, and each gives only what that job needs.
• New roles were tested by someone who isn’t an Owner.
• People who left have been removed from People.

Sharing and AI

• Your team knows to pick the shortest share link lifetime that works, and never to share sensitive files by public link.
• AI clients use small roles made for them. (How)
• Clients that are no longer used have been revoked on AI agents, using the Everyone tab.

Every few months

• Rotate each connection’s key.
• Look through the audit log for denied actions and failed sign-ins. Export anything you need to keep beyond 14 days.
• Run Test connection on each connection, especially after changes at your provider.
• Review who has which role on People.

Before storing sensitive data

quickS3 uses long-lived access keys, keeps its audit log for 14 days, and has no compliance certifications. Read the security model and decide whether that fits the data you want to put behind it.