Rights management

Self-organising teams distribute authority through roles and circles. Nestr’s rights management lets your permission model do the same thing. Define what every member can read, create, update, and delete through named profiles, and attach those profiles to people directly or to the roles they fill. Anyone stepping into a role picks the rights up. Anyone stepping out loses them. Authority follows the work, not the person.

What problem does rights management solve?

Most tools offer two settings: everyone-can-do-everything, or admin-only. Self-organising teams need more nuance than that. The Finance circle needs to see budget items their colleagues should not. A Project Lead role needs to assign people to its projects without being a full circle admin. Auditors need to read but not change. Read-only stakeholders need a view that costs less than full access.

Rights management gives you these distinctions without bolting a separate access-control system onto your workspace. Permissions become part of governance, written in the same vocabulary as roles, circles, and labels.

What makes Nestr’s rights management different

Most self-organisation tools treat access as a fixed tier: member, admin, owner. That works until you need anything more nuanced than “trust them with everything or nothing”. Nestr is in a class of its own here: a full permission profile editor that lets you shape role-based access control to match how your organisation actually works.

• Per-label and per-field grants: control read, create, update, and delete on any system label, any custom workspace label, or individual fields like Users, Description, or Due. No need to hand someone the keys to a whole area because you wanted them to update one field.
• Four scopes: workspace, circle, circle plus sub-circles, and tree. Rights apply exactly where they are meant to, including a strict circle scope that holds the line at sub-circles.
• Tri-state grants: Yes, No, or Default. Default lets Nestr’s built-in behaviour handle operations you do not want to override, so profiles stay small and intentional.
• Row-level limits: scope a rule to everyone in the context, only people assigned to the item, or only people assigned to the parent. Useful for “you can edit the projects you are on, not the ones others are on”.
• Profiles that stack: a person filling multiple roles in a circle inherits all the matching profiles at once, merged using the most permissive value. Unassignment from one role does not affect the rights held through the others.
• Self-serve, no support ticket: workspace admins build and update profiles in the editor. No plan negotiation, no “contact us to enable”.

How does rights management work in Nestr?

Three layers stack to produce what each member can do for any given item:

• Default member rights: a workspace-wide baseline plus an optional baseline for circle members. Use this to widen or narrow the standard behaviour for everyone in one place.
• Custom profiles: named bundles of rights you build in the editor. Each profile carries a scope (workspace, circle, circle plus sub-circles, or tree) and a grants matrix covering read, create, update, and delete on any nest type or label, with optional sub-rules for assignability, comments, and individual fields.
• Two assignment paths: hand a profile directly to a member from the workspace users page, or attach it to a role so anyone filling the role inherits the rights inside the role’s circle. Stepping into the role grants the profile. Stepping out revokes it. Multiple roles stack using the most permissive value.

Role bleed: keeping agents and humans in their lane

Role bleed is what happens when a person or an AI agent acts beyond the purpose of their role simply because nothing technical stops them. With humans the consequences are usually slow and visible. With AI agents the same drift can happen in a single session, at machine speed. The role definition said “do A” but the system still allowed A, B, and C, so the agent did all three.

Rights management is the enforcement layer that closes the gap. Roles set the lane through their purpose, accountabilities, and domains. Rights management is what makes those boundaries technical instead of aspirational. The model maps directly onto two industry-standard concepts:

• Role-based access control (RBAC): permissions hang off roles, not people. Nestr’s grants matrix and scope model is RBAC by construction.
• Agent identity and scoped credentials: each agent has an identity in Nestr, holds rights only via the roles it currently fills, and every access decision is captured in the same audit trail as human work.

Combined with permission creep prevention and the broader practice of agent governance, rights management gives you “cannot, by construction” instead of “we asked it nicely”.

Why this matters for AI agent governance

When AI agents fill roles in your organisation, their access should be managed in the same place as the humans they work with, not in a parallel system. Rights management ties an agent’s permissions to the role it is filling. Update the role’s rights field and every agent (or human) in the role picks up the change. Unassign the agent and the rights are revoked the same way. The model satisfies the role-scoping requirements that EU AI Act and other emerging frameworks expect, without forcing you to maintain a separate access-control stack alongside Nestr.

Who is rights management for?

Rights management is part of the Pro plan. It is the right fit for organisations that need to express access control in role terms: regulated industries, teams preparing for AI agent deployment, larger workspaces with mixed-permission stakeholders, and any group that wants permission boundaries to evolve as their structure does.