Add Access Policies

Kizaki policies are declarative. You define who can act on which rows, and the runtime enforces those rules everywhere.

That is one of the central Kizaki ideas. Authorization should not be something every handler remembers to do manually. It should be part of the model of the data itself.

Start With Ownership

For first apps, ownership policies are usually enough:

entity Project {
  name: string,
  ownerId: __User.id,

  @grant read, write, delete where resource.ownerId == principal.id
}

This one rule applies across:

• server-side queries
• generated client calls
• browser live queries
• related data loaded through includes

If your product has a clear concept of “my data”, ownership should usually be your first policy tool. It is simple, readable, and difficult to misinterpret later.

Add Roles When Needed

entity Invoice {
  total: decimal(10, 2),
  accountId: Account.id,

  @grant read to role(Admin)
  @grant read where resource.accountId == principal.accountId
  @deny delete to *
}

Use roles when access should be organizational rather than personal.

Good role design tends to stay small:

• Admin
• Manager
• Billing
• Support

When in doubt, prefer a small set of durable roles over a large matrix of narrow permissions in the first version of the app.

Keep App Code Thin

The recommended pattern is:

• schema owns authorization
• server functions own workflow
• frontend owns presentation

Avoid hand-written permission branches in the UI whenever the rule can live in Inspire instead.

A Good Policy Design Sequence

For most apps, the clean order is:

1. ownership rules first
2. role-based reads next
3. role-based writes when needed
4. deny rules for hard invariants

That sequence gives you policies that stay readable even as the app grows.

Next Step

Once access rules are in place, you can add business logic. Continue with Write Server Functions.