Skip to main content

Sharing and permissions

How access works: company roles, per-resource access levels, sharing, and AutessaDB row/column security — and what the SDK deliberately does not expose.

The decision: you built something. Who can see it, edit it, or run it — and how do you control that from a script?

The layers​

  • Company roles. Every member holds a role in the company. There are six built-in roles; "User" is the base role granted on auto-join. List them with autessa.company.role.all. Roles gate what a member can do at the company level.
  • Per-resource access levels. Resources (agents, tools, tables, connectors, apps, scheduled events, e-signature templates, …) are shared at an access level: READ, WRITE, PUBLISH, or ADMIN, in increasing power. Most resource namespaces expose a matching pair — a getSharingDetails to see who has what, and a share to grant or change it, e.g. autessa.autessadb.tables.getSharingDetails and autessa.autessadb.tables.share.
  • AutessaDB row/column security (RLS/FLS). Within a table, roles decide which rows a user sees and which columns are masked. Table security is default-open: a table with no role rules is fully visible, and a masked column needs an explicit role rule to hide it. Manage table roles with autessa.autessadb.roles.create, .update, and .list. Every query runs under an acting identity, which is what the row/column rules are evaluated against.

Decision rules​

  1. Grant the least level that works. READ to look, WRITE to edit rows/config, PUBLISH to publish a new version, ADMIN to manage sharing itself. Don't hand out ADMIN to let someone merely edit.
  2. Auto-join grants "User", never "Admin". When wiring up membership, the base "User" role is the default; elevate deliberately.
  3. Table security is opt-in. If a table holds sensitive rows or columns, add explicit role rules with autessa.autessadb.roles.create — otherwise it is open by default.
  4. Check before you assume. Use the resource's getSharingDetails to read the current grants before changing them.

Worked examples​

A. Share a table read-only with a team. autessa.autessadb.tables.share at READ, then confirm with autessa.autessadb.tables.getSharingDetails.

B. Hide a salary column. Add a table role via autessa.autessadb.roles.create that masks the salary column for the base role, leaving it visible only to a privileged role — because without a rule the column is open.

What the SDK deliberately does NOT expose​

Some administrative actions are intentionally out of scope for scripts — for example transferring ownership of a resource is not a scriptable operation. Sharing and access-level changes are scriptable; wholesale ownership transfer is not.

See also​

  • data-placement — the tables these rules protect.
  • connectors — connectors follow the same share/access-level model.