Access control

NIST SP 800-53 AC-3 calls this access enforcement: the system allows approved authorizations and denies the rest. A policy document that nobody's server reads is not the control.

For transfers the identity is a user, a key, or the mere holder of a URL. The action is read, write, delete, or grant. The object is a key, a prefix, or a link. A rule written as "finance can read `/payroll`" is useless until the server checks it on GET and writes a deny when the check fails. RFC 9110's 401 and 403 are how that deny looks on the wire.

A bucket policy allows the role `acct-export` to PUT to `outbound/acct/` and allows the vendor key to GET that prefix and nothing else. On Tuesday the vendor key requests `outbound/hr/salaries.csv`. The store returns 403, and the access log records the deny. A shared admin key used by a script would have succeeded, because the rule was on the role and the script did not use the role. The failure mode is a broad key "so the job stops breaking," which quietly voids the prefix split. Encryption at rest does not replace this. An authorized caller receives plaintext from the API even when the disk holds ciphertext.

Granting is its own action. A user who can create a public link can undo a private policy without changing the policy file. Controls that ignore link creation watch the wrong door. Permission management is the day-to-day editing of these rules. It is not a separate mechanism. The audit question is whether the log shows the grant, the use, and the revoke as three rows.