Humans, portals, agents, and service accounts are different identities
A useful permission model distinguishes how people and machines enter an operational system and what each can do.
A person using the internal application, a customer in a portal, an AI Agent, an automation, and an API integration may all touch the same operational data. Treating them as interchangeable “users” hides important control decisions.
Human seats should represent people who can use the internal product. Portal identities should be external and scoped to the records and actions exposed to them. Agents and automations need explicit tools and permissions. API keys and Service Accounts need ownership, revocation, and audit without a shared human login.
The permission question is not only “can this identity edit the table?” It is also:
- Which records can it discover?
- Which fields can it read or change?
- Which actions can it invoke?
- Can it export or access an API?
- Does the same policy apply in an automation or agent tool?
Bondi Standard includes role-, screen-, and action-level permissions. Pro adds record and field controls, custom roles, approval flows, and Service Accounts. Enterprise adds SSO/SCIM and contractual security options.
Build your first system
Start a 30-day trial. No card required.