Access Control

Atom answers one question:

Can subject S perform action A on object O?

Example:

Can device meter-001 publish to channel telemetry?

The Model

Subject gets a Role.
Role contains Permission Blocks.
Direct Policy gives a Subject one Permission Block directly.
Permission Block is the only place where scope and actions are defined.

Vocabulary

Core Rules

• Deny overrides allow.
• No matching allow means denied.
• Tokens do not contain permissions.
• Scope and actions live in permission blocks.
• Role assignments do not define scope.
• Direct policies do not redefine scope.
• Assignment guardrails prevent unsafe access state from being created.
• Groups do not grant access by themselves; assignments and permission blocks do.

Actions And Applicability

Actions are global operation names. Atom uses names such as read, write, delete, publish, subscribe, execute, manage, create, revoke, rotate, policy.manage, role.manage, and authz.check.

Do not model object-specific action names such as client_read, channel_publish, or report_execute. The action stays global; Action Applicability decides where that action is valid.

Action Applicability validates action/object pairs. It does not grant access by itself.

Examples:

Invalid pairs, such as publish on an entity or execute on a channel, are rejected before permission blocks are evaluated.

Assignment Guardrails

Assignment Guardrails validate whether it is safe to create access state, such as a role assignment, direct policy, role-to-permission-block link, or group membership that would grant inherited access.

They are different from runtime authorization. /authz/check answers whether the current subject may perform the current action on the current object. Assignment Guardrails run when access is being assigned or changed.

For example, Atom can allow devices to receive publish on resource:channel, while denying devices from receiving manage on resource:channel.

Where To Go Next