Field-level access
A field can name which kinds of caller may read it and which may write it. An internal note can be kept to your team, and a value that an operation sets can be kept out of the user's browser.
Read and write lists on a field
A field takes an optional access object with a read list and a write list. A write list with entries is an allow-list, and the platform rejects any other caller on every write path. The read list governs which callers the client API exposes the field to. A field with no access object is writable by any authenticated caller.
Five kinds of caller
Every request is one of five kinds, decided by the credential it carries. A visitor who is not signed in is public. A signed-in user writing with their own token, on your public key, is self. An operation acting with the token issued for its run is scoped, even when that token carries the user who triggered it. A secret key is service. A person on your team, in the console or the CLI, is admin.
A field only an operation may touch
A user who runs an operation is still that user for ownership, row rules, the audit actor and quotas. What the operation reads and writes counts as scoped and never as self. So a field that lists scoped and leaves self out is read and set by the operation, and the user's browser can do neither.
How a read is judged
The data API judges reads by the same five kinds. An operation reads as scoped, and a signed-in user's own request as self. A visitor and a secret key both read as public, and a team member previewing in the console reads every field. A cached response computed for one kind of caller is never served to another.
Read the detail
The models reference shows the access object on a field, the five kinds of caller and a worked example for an operation.