LayBuild has four fixed roles: Owner, Admin, Agent and Customer, ranked in that order. There are no custom roles, no SSO or SAML login, and two-factor authentication is a per-user TOTP opt-in. If you need fine-grained permissions or identity-provider login for your support team, LayBuild doesn't offer that today. If a small team with clear "admin" and "agent" jobs is what you have, the model below is probably enough, and this post tells you exactly where its edges are.

The four roles

Roles are ranked numerically (Owner 4, Admin 3, Agent 2, Customer 1). A route that requires a role accepts that role and anything above it, so an endpoint open to Agents is also open to Admins.

text
OWNER     platform operator: every workspace, impersonation, plan overrides
  |
ADMIN     runs one workspace: knowledge, AI agents, settings, team, audit log
  |
AGENT     works the inbox: claims, hands off and replies to conversations
  |
CUSTOMER  the person chatting: sees only their own conversations

Each workspace (organization) keeps its own membership list with a role per member, and data queries are scoped to the workspace you're acting in. For how that scoping works under the hood, see how LayBuild keeps tenants apart.

Owner

Owner is the platform operator role, not "the person who pays for a workspace". On our hosted service that's us. If you self-host LayBuild, it's you: the bootstrap seed creates an owner account. An Owner can open any workspace, change plans and subscription state, and impersonate a user to see what they see. Starting and stopping impersonation are written to the audit log as admin.impersonate and admin.stop_impersonate. On a self-hosted install, treat the Owner account like a root credential: few people, strong password, two-factor on.

Admin

The person who registers a workspace becomes its Admin. Admins can do everything inside that workspace:

  • manage knowledge: upload files, add URLs, edit Q&A pairs, delete documents, including ones the learning loop published on its own
  • create and configure AI agents, prompts and guardrail settings (blocked terms, PII redaction, the refusal message)
  • set up API tools, outbound webhooks, the widget and its allowed domains, SMTP and WhatsApp
  • invite teammates as Admin or Agent, change roles, remove members
  • read analytics and the audit log

Admins can't demote themselves, which stops a workspace from being left with no one in charge by accident.

Agent

Agents are the humans who pick up conversations. They can claim a conversation, hand it off, transfer it to a colleague, resume AI replies, ask the customer for a rating, and rename a conversation. They can see the list of human agents for transfers and open the original files behind knowledge documents. They can't change knowledge, AI agents, settings, tools, webhooks or the team.

Customer

Customer is the role for the person on the other side of the chat. A widget visitor or a WhatsApp contact gets a Customer account when their conversation starts. Customers see their own conversations and notifications and nothing else.

What the AI agent is allowed to do

The AI doesn't act with anyone's role. It reads from the workspace's knowledge base and writes replies to the conversation it's answering. The only outside systems it touches are the API tools an Admin attached to that AI agent, and those are called with the configuration the Admin saved: fixed URL, fixed default parameters, fixed credentials. The model can't choose which tool to call or pass it arguments. That limits what a prompt-injection attack can make it do, and it also means least privilege lives in the tool's credential. Give each tool a key that can only read the one endpoint it needs. The Postgres and Supabase guide walks through that.

One role per person, in practice

Permission checks on API routes read the role stored on the user's account. The workspace membership table records a role per workspace, and for someone who belongs to one workspace the two are the same. If you add one person to several workspaces with different roles, the account-level role is the one the checks use. The safe approach today is to give that person the lowest role they need everywhere, or give them separate accounts.

The audit log

LayBuild writes an audit entry for security-relevant and configuration actions. Each entry records the actor, the workspace, an action name, the affected entity and a JSON details field. Actions include:

  • account and security: 2fa.enabled, 2fa.disabled, password.reset, session.revoked, session.revoke_all
  • team: team.invite_create, team.invite_revoke, team.role_change
  • configuration: agent.update, guardrails.update, prompt.update, org.widget.secret_regenerate
  • knowledge: knowledge.create, knowledge.delete, knowledge_qa.update
  • conversations: conversation.claim, conversation.handoff_requested, conversation.close
  • data requests: gdpr.export_request, gdpr.delete_request

Admins read it in the dashboard, filtered to their workspace, and can narrow it to one conversation. It answers questions like "who changed the guardrail settings on Tuesday" or "who took over this conversation". It isn't a SIEM feed; if you need entries in your own logging stack, a self-hosted install lets you read the AuditLog table directly.

Two-factor authentication

Any user can turn on TOTP two-factor login with an authenticator app: scan the QR code, confirm a code, and from then on login asks for a 6-digit code. Codes use 30-second steps and one step of clock drift is accepted either side. Enabling and disabling are both audited, and disabling requires a valid code.

The limits: an Admin can't require two-factor for everyone in the workspace, and there are no recovery codes. Decide how you'll handle a lost phone before your team depends on it.

What's missing

  • SSO and SAML. There's no login through Okta, Google Workspace, Microsoft Entra or any other identity provider, and no SCIM provisioning. Offboarding means removing the member in LayBuild as well as in your directory.
  • Custom roles. You can't create "knowledge editor" or "read-only analyst". Anyone who edits knowledge is an Admin and can also change webhooks and the team.
  • Scoped agents. An Agent's access is to the workspace inbox, not to a subset of queues, channels or AI agents.
  • Enforced two-factor, as above.

If any of these is a hard requirement from your security team, say so to us at [email protected]. We'd rather hear it before you buy than after.

A setup that works with these limits

  • Keep the Admin list short. Most of your support team should be Agents.
  • Turn on two-factor for every Admin, and for the Owner account on a self-hosted install.
  • Give each API tool and webhook its own narrowly scoped credential.
  • Check the audit log after role changes and after anyone edits guardrails or prompts.
  • When someone leaves, remove them from the workspace the same day.

Related reading