Security and data isolation

agaro uses the workspace as the tenant isolation boundary. Product security combines authenticated user context, workspace scoped application queries, PostgreSQL row level security on protected tenant tables, module and role gates, and action specific validation.

This page describes implemented controls. It is not a claim of a certification, legal compliance status, or guarantee against every security failure.

#Workspace isolation

Tenant records carry a workspace identifier. Authenticated actions resolve the active workspace from the live user or actor bound API key and include that workspace in data access.

Protected database tables also use forced row level security policies. The application sets the current workspace context for a tenant operation, and the database rejects rows outside that context. Cross tenant platform tables use separate privileged boundaries because they do not belong to one workspace.

Do not use exported identifiers from one workspace in another workspace's API request. A not found result can intentionally hide whether a foreign record exists.

#Live authorization

Actions do not rely only on what was placed in an old browser session. Sensitive authorization paths revalidate current user state, workspace, role, approval, suspension, and module access.

A role change, suspension, deletion, key revocation, module removal, or subscription change can therefore affect the next request without waiting for a long session expiry.

#User roles

Role is the starting point, not the entire permission model. App access, access groups, model permissions, record scopes, record rules, field visibility, menu visibility, and module entitlement can narrow it.

#Access Rights

Authorized administrators open Settings → Security and Access → Access Rights. The available tabs include:

• Groups and permission set membership
• App access
• Model permissions for Read, Create, Write, and Delete
• Record scopes for supported data areas
• Record rules
• Field visibility
• Menu visibility

Use least privilege. Grant a team the data and actions needed for its work rather than copying Super Admin access to avoid configuration effort.

UI hiding is not the enforcement boundary. Server actions recheck permission even if a user calls a route or action directly.

#Workspace read only state

Subscription status can place the workspace into a read only state. Reads remain available where supported, while business mutations, assistant turns, and API mutations are refused. Narrow billing recovery actions remain available to a billing administrator.

Read only is a commercial access control, not a backup strategy. Continue normal data export and recovery planning.

#Passwords and sessions

Normal credential sign in uses email and password. Password activation and password recovery use separate purpose bound, single use links. A staff invitation cannot be reused as a password reset token.

Session state includes a version so high impact account changes can invalidate older sessions. Security cookies used for second factor completion are signed and bound to the current user and session.

#Two factor authentication

Users can enroll an authenticator app or email code under Account Settings → Security and Privacy. Workspace policy can keep enrollment optional, require employees, or require everyone, with a configurable grace period.

See Two factor authentication and access policy for setup and recovery.

#API and MCP keys

Current keys are actor bound. They can act only as an active approved Super Admin or Manager in the same workspace, cannot be elevated by request headers, and require an active MCP seat for the actor.

Only a SHA 256 hash of the key is stored. The plaintext is revealed once. Keys support expiry, immediate rotation, immediate revocation, last used time, and call count. API and MCP requests are rate limited per actor and workspace.

Rotate a key when its storage location or audience changes. Revoke it immediately if exposure is suspected.

#Stored integration secrets

Supported provider credentials and App Builder secrets use encrypted storage. Interfaces show connection state and metadata rather than returning saved plaintext.

Never paste credentials into an ordinary record, task, assistant conversation, email template, or generated site source. Use the integration form or secure App Builder credential request designed for that secret.

#Money controls

Business money is stored in integer minor units rather than binary floating point. Currency is carried with supported records and provider operations.

Payment and billing flows use provider identifiers and idempotency keys where needed to reduce duplicate processing. Webhook handlers verify provider signatures, bind events to workspace evidence, and record replay state for supported flows.

The platform subscription account, tenant customer payment account, and agency client collection account are distinct. agaro does not silently use platform billing credentials for a tenant's customer charge.

#Activity and audit evidence

Business actions can create activity records attributed to the acting user. Agency support access includes agency actor context. Settings includes a recent configuration audit, and many record pages show a related activity rail.

Audit history covers product actions that are explicitly recorded. It is not a complete network or endpoint security log and not every screen view is guaranteed to create an activity row.

#Data export and deletion requests

Workspace privacy controls provide the supported request path for workspace data export and deletion. Individual module trash is for operational recovery and does not replace a formal deletion workflow.

Deleting an assistant conversation permanently removes that user's transcript. Other business records often use soft deletion and can be restored from Recently deleted.

#Secure operating checklist

1. Require two factor authentication for the appropriate population.
2. Keep at least two trusted Super Admins where business continuity requires it, but avoid unnecessary administrators.
3. Use access groups and record scope instead of shared accounts.
4. Review suspended, pending, and inactive users regularly.
5. Use expiring API keys and rotate them.
6. Remove personal provider connections during offboarding.
7. Review settings activity and provider billing events.
8. Test backups and exports outside an incident.
9. Confirm the active workspace before agency support changes.
10. Report suspected exposure and revoke affected credentials immediately.

#Troubleshooting

#A user sees forbidden after a role change

Confirm their current workspace, role, app access, group membership, model permission, record scope, and module entitlement. Sign out and back in if the browser still shows stale navigation.

#A key stopped working after personnel changes

Actor and creator authority are live. A suspended, deleted, removed, or demoted user can invalidate the key's usable scope. Create a new key bound to the correct active actor.

#A cross workspace record returns not found

This is expected isolation behavior. Switch to the authorized workspace rather than trying to reuse the identifier.

#A mutation says read only workspace

A Super Admin should restore the subscription from Settings → Subscription. Do not attempt to bypass the mutation gate through API or MCP.