teams

Roles and permissions

Understand how OpenbirdAI team roles limit what a member can see and do, and why authorization is enforced per request.

Last verified 13 October 2026 · OpenbirdAI documentation

Roles decide what each member of a team workspace can read and change. OpenbirdAI enforces them server-side on every request, so a hidden button is a usability affordance — not the security boundary.

This guide describes a capability that depends on the connected provider, the permissions granted to it, and your current plan. If the provider cannot supply the required data, OpenbirdAI reports it as unavailable rather than estimating.

How permissions are decided

Authentication — who you are.
Workspace membership — which workspace the request runs in.
Role — what that role permits in this workspace.
Resource permission — whether this specific record or connection is accessible.

All four must pass. Failing any one of them results in an unavailable result rather than a partial leak.

Roles you will see

Owner or admin — workspace configuration, members and connections.
Member — normal use of the workspace's data, memory and tools.
Restricted member — a narrower set of capabilities where supported.

The exact role set depends on plan and configuration. Do not assume a role exists because it exists in another workspace.

Why a member sees less than you expect

They are in a different workspace than the connection.
They are in the right workspace but lack a required role.
Their request ran in a workspace they can read but not one that owns the data.
They are relying on conversation context created in a workspace they cannot access.

Escalation and least privilege

Grant the smallest role that lets someone do their work, and review membership periodically. When someone changes role, re-test what they can and cannot see rather than assuming the change applied everywhere.

If a member can read data you did not intend them to see, remove their access first and report it. Do not attempt to work around it.

Reviewing access periodically

Roles drift: people change jobs, projects end, and temporary access becomes permanent. A short review every quarter catches most of it.

List current members and compare each to who genuinely needs access today.
Downgrade anyone who only occasionally needs the workspace.
Remove anyone who has moved on.
Re-test one member's access afterwards to confirm the change applied.

Common questions

Does hiding a button enforce permission?

No. Permissions are enforced server-side. Hidden controls are only a usability signal.

Can a member escalate their own role?

No. Role changes require an owner or admin, and are validated server-side.