Give people exactly
the access they need
Per-resource permissions, per-team channel access, encrypted credentials, guardrails on what agents may say, and a log of every run — so putting AI in front of customers is a decision you can defend.
Governance that survives the second team
The controls that decide whether AI can be trusted with a real customer conversation.
Roles that fit the job
Owner, Admin and Member out of the box, and custom roles when those do not fit. Permissions are granted per resource and per action, so "runs the inbox, never sees billing" is a role rather than a rule someone has to remember.
Per-resource sharing
An agent, a document, a folder, a tool or a board carries its own access list on top of roles — view, comment, use, edit or admin, granted to a member, a team, or everyone.
Channel-level separation
Assign a Page, a Zalo account or a widget to a team, and the inbox they open holds only the conversations from it. What an agency needs, and what a support team on one product needs.
Secrets that stay secret
Database credentials, channel tokens and endpoint auth headers are encrypted at rest and never returned to the browser. Forms report that a secret is configured; they do not re-display it.
Guardrails on what agents may say
Policies applied to what goes into an agent and what comes out, with an audit of which guard fired, what it did, and why — so a blocked reply is a record, not a mystery.
A log for every kind of run
Agent executions with their tool calls and cost, scheduled task runs, webhook deliveries, care sends and platform errors — each with its own list rather than one undifferentiated stream.
What you can control
Access, data handling, visibility and continuity.
Identity and access
- Owner, Admin and Member system roles
- Custom roles with per-resource, per-action grants
- Teams, with leads and members
- Around thirty permission resources
- Invitations, and access revoked from one screen
Resource-level sharing
- Five levels: view, comment, use, edit, admin
- Granted to a member, a team, or the workspace
- Applies to agents, documents, folders and tools
- Applies to knowledge bases, channels, data sources and boards
- Share-by-link documents, with the level you choose
Data handling
- Workspace isolation on every request
- Credentials encrypted at rest
- Secrets never returned to the browser
- Read-only database connections where you want them
- External customer data fetched, not silently copied
Visibility
- Per-run execution logs with tokens and cost
- Guardrail audit — which fired, and what it did
- Scheduled run history
- Webhook delivery log
- Platform error log
Backup and continuity
- On-demand and scheduled backups
- Restore back into the workspace
- Export of workspace data
- Storage usage visible per workspace
Programmatic access
- API keys scoped to their creator’s permissions
- The same key authenticates the MCP endpoint
- Keys revocable individually
- Per-call logging with cost attribution
What changes when access is granular
The workarounds that stop being necessary.
Everyone who can log in can see everything, because access is all-or-nothing
Per-resource, per-action permissions, plus a per-resource access list
Giving a contractor one Page means handing over the whole workspace
Channel access assigned to a member, a role or a team
An API token pasted into a config file and shared around the team
Credentials encrypted at rest, never displayed again after they are saved
An AI reply that went wrong, and no way to see what it did or what it cost
A per-run log with every tool call, every guard outcome and the cost of each step
Backups that exist if someone remembered to run one
Scheduled backups, with restore into the workspace
Security and governance questions
What an administrator checks before the second team is invited in.
Permissions are granted per resource type and per action — reading agents, creating tools, exporting backups, starting a training run and about thirty other resources are all separate grants. Three roles exist out of the box (Owner, Admin, Member) and you can define your own, so "can answer the inbox but cannot touch billing" is a role rather than an exception someone has to remember.
Yes. On top of role permissions, individual resources — agents, documents, folders, tools, knowledge bases, channels, data sources and boards — carry their own access list. You grant a member, a team, or the whole workspace one of view, comment, use, edit or admin on that specific thing.
That is exactly what channel access is for. A Page, a Zalo account or a widget is assigned to a member, a role or a team, and the inbox they open contains only the conversations from what they hold.
Encrypted at rest, and never sent back to the browser. A settings form that shows a connected integration reports that a secret is configured; it does not re-display the value. That applies to database connections, channel tokens and the auth headers on enrichment endpoints alike.
Every run is logged end-to-end: the messages, the tools it called and what they returned, the tokens and cost per step, and which guardrails fired and what they did about it. Separate logs cover scheduled runs, webhook deliveries, care sends and platform errors.
Backups can be run on demand or on a schedule and restored into the workspace. Deletion is a first-class action rather than a support ticket: a member can delete their own account from the site, and workspace data goes with the workspace.
Set it up the way your team is shaped
Roles, teams and per-resource access are there from the first workspace. Free to start, no credit card.