Roles and permissions

Start with workspace rolesCopy Anchor Link

Owners administer the workspace and retain full project access. Administrators manage the workspace according to its role rules. Members have baseline editing access, and viewers are read-only. Database privileges still bound what the agent can do.

Narrow access with a project roleCopy Anchor Link

On plans supporting custom roles, configure them in the project's role settings. A custom role can control collections, fields, rows, and named actions. It replaces the member's baseline project data permissions; anything not allowed by its rules is denied.

For example, these rules let a user read and update tickets assigned to their Aviato user ID:

[
  {
    "action": ["read", "update"],
    "subject": "tickets",
    "conditions": { "assignee_id": "{{user.id}}" }
  }
]

Make sure assignee_id actually stores Aviato user IDs before using this example. A business application's user identifier may be different.

Field access and filtersCopy Anchor Link

A caller who cannot read a field must not be able to infer it through filters. The agent checks filters against field permissions and projects mutation responses through read permissions as well.

Role changes apply to new agent sessions; an existing short-lived session can retain its previous role until it expires. Approval execution refreshes membership and custom-role definitions at claim time.

MCP scopes are an additional restrictionCopy Anchor Link

A connection granted only aviato:read cannot write through a custom role. Use separate accounts and roles for distinct operational responsibilities, and inspect audit activity when validating access.

See the role-rule reference for condition syntax and assignment behavior.