Permission Blocks

A permission block is the single source of access logic in Atom.

It answers:

Where does this rule apply?
Which actions are covered?
Is this an allow or a deny?
Are there extra conditions?

Fields

Field	Meaning
`tenantId`	Tenant boundary for the rule.
`scopeMode`	How broad the rule is.
`objectKind`	Protected object category, such as `tenant`, `entity`, `resource`, `group`, `role`, `policy`, `credential`, `audit_log`, or `signing_key`.
`objectType`	More specific type, such as `resource:channel` or `entity:device`.
`objectId`	Exact object ID when the rule targets one object.
`groupId`	Object group ID when the rule targets objects in a group.
`effect`	`allow` or `deny`.
`conditions`	Optional flat JSON conditions.
`actions`	Operation names covered by the rule.

Every action in a permission block must be valid for the block's target object kind/type through Action Applicability. Applicability only says an action can be used with that kind of object; it does not grant access until the action appears in a matching permission block.

Object Kinds And Types

Atom's canonical protected object kinds are:

entity
resource
group
tenant
role
policy
credential
audit_log
signing_key

objectType is used for finer sub-kinds and is stored with a kind prefix, such as entity:device or resource:channel. Kinds without sub-kinds use objectType = null.

Common Scope Modes

Scope mode	Meaning
`platform`	Applies at platform level.
`tenant`	Applies to the tenant/domain object.
`object_kind`	Applies to all objects of one category.
`object_type`	Applies to all objects of one type in a tenant.
`object`	Applies to one exact object.
`group`	Applies to the object group itself.
`group_direct_objects`	Applies to objects directly inside an object group.
`group_descendant_objects`	Applies to objects inside child or deeper object groups.
`group_child_groups`	Applies to immediate child object groups.
`group_descendant_groups`	Applies to child and deeper object groups.

Roles And Direct Policies

A permission block can be used in two ways:

attach it to a role, then assign the role;
attach it directly to a subject with a direct policy.

Use roles for normal administration. Use direct policies for narrow runtime links or special security cases where a named role would add noise.

Deny Rules

A deny permission block blocks access even when another permission block allows it.

Example:

Allow: Plant-A devices can publish to Plant-A channels.
Deny: meter-001 cannot publish to channel alerts.
Result: meter-001 is denied for alerts but still allowed for other Plant-A channels.