Quick Start

Sign in

Open http://localhost:3005/login and sign in with admin / 12345678 (the default dev credentials — change ADMIN_SECRET in .env before running this anywhere else). You land on the Dashboard, which summarizes tenants, entities, roles, and platform activity.

Create a tenant

Open Tenants in the sidebar. The table is empty on a fresh instance. Click + Create in the top-right corner.

Fill in:

• Name: acme-corp
• Alias: acme

Leave Tags and Attributes JSON empty, then click Save tenant.

The new tenant appears in the table with row actions Inspect, Edit, Freeze, Disable, and Delete. Click Inspect if you want to copy its ID — you won't need it for this walkthrough since every later form lets you pick acme-corp by name.

Switch your working context to the new tenant using the Global / platform switcher at the top of the sidebar, or leave it on Global and pick acme-corp explicitly in each form below — both work, since every create dialog has its own Tenant field.

Create two entities

Open Entities. Click + Create.

Create the first entity:

• Name: Alice
• Kind: human
• Tenant: acme-corp
• Leave Profile as No profile.

Click Save entity. Repeat for a second entity:

• Name: billing-service
• Kind: service (the Kind dropdown also offers device, workload, and application — pick whichever matches what you're modeling)
• Tenant: acme-corp

Both entities now appear in the table, alongside any entities Atom seeded on first boot (admin, example-service).

Create a resource

Open Resources. The table starts empty. Click + Create.

Fill in:

• Kind: invoice
• Name: invoice-events
• Tenant: acme-corp
• Leave Owner entity and Attributes JSON at their defaults.

Click Create resource. Open the new row's Inspect view and copy the ID — you'll paste it into the permission block scope in a later step.

Tell Atom which actions apply to invoices

Actions like read and write already exist platform-wide (Atom seeds a standard catalog), but Atom still needs to know that read and write are valid for the invoice resource kind. Open Actions → Action Applicability and click + Create.

Create one row for read:

• action_id: read
• object_kind: resource
• object_type: resource:invoice

Click Create row, then repeat with action_id set to write (same object_kind and object_type). See Actions for what Assignment Guardrails (the third tab in this section) is for — you don't need it here.

Create two permission blocks

Open Permission Blocks and click + Create. This is a 5-step wizard.

Block 1 — read + write.

1. Boundary — set Tenant boundary to acme-corp, leave Effect as allow.
2. Scope — set Scope mode to Exact object, Object kind to Resource, enter Object type resource:invoice, and paste the invoice-events resource ID into Exact object ID.
3. Actions — check both read and write.
4. Conditions — leave the JSON as {} (no ABAC conditions for this walkthrough).
5. Review — confirm the summary, then click Create permission block.

Block 2 — read only. Repeat the wizard with the same tenant, scope, and object ID, but check only read in the Actions step.

Both blocks now appear in the table, alongside the seeded platform and tenant-admin blocks.

Create two roles

Open Roles and click + Create. This is a 3-step wizard: Basics, Permission blocks, Review.

Create invoices-reader:

1. Tenant: acme-corp. Role name: invoices-reader.
2. Under Permission blocks, use the Add permission block dropdown and pick the read-only block (resource ... · allow · read).
3. Review, then Create role.

Create invoices-reader-writer the same way, attaching the read+write block instead.

Grant access with direct policies

Open Direct Policies and click + Create. This is a 4-step wizard: Tenant, Subject, Permission block, Review.

Alice's policy — read-only:

1. Tenant boundary: acme-corp.
2. Subject kind: Entity. Subject: Alice (human).
3. Permission block: the read-only block.
4. Review, then Create policy.

billing-service's policy — read+write: repeat, picking billing-service (service) as the subject and the read+write block.

Check authorization

Open Authorization. This is the authorization debugger — pick Who, Can do, Target type, and Resource, then click Explain decision.

Run all four combinations from this scenario:

For billing-service reading, the decision panel shows Allowed, the matched permission (effect: Allow, action: read, scope exact object <resource id>), and — because the same block also grants write — a second matched permission for that action too.

For Alice writing, the decision is Denied with reason no matching allow policy. The panel also shows why it isn't a coincidence: Alice's read-only permission block is Skipped — Action not covered by this grant, and it even surfaces an unrelated inherited role (domain-creator, via the seeded authenticated-users principal group) that also doesn't cover write.