Safety & Read-Only Agents

Giving an AI agent access to your business account deserves care. Zingasuite is built so you can do it safely, with the same guardrails as the rest of the platform.

Least privilege: prefer read-only

Start every agent with a read-only key (data:read, messaging:read). It can look at everything and search your docs, but it cannot create, change, delete, or message. Only grant write scopes when the agent genuinely needs to act, and grant the narrowest scope that works — e.g. data:write:products rather than data:write:* if it only manages the catalog.

Three independent guardrails on every action

A tool call only succeeds if it clears all three:

1. Key scope — the key must carry the required scope (e.g. data:write:orders).
2. Member role — a key can never do more than the team member who created it; if their role loses an ability, so does the key.
3. Per-model permissions — where a member has table-level permissions configured, those still apply to the agent.

Secrets are never exposed: credential-bearing resources (payment gateways, carrier integrations) can't be created or read through the agent, and secret columns are never returned.

Writes are auditable and mostly reversible

• Order imports accept an externalId for idempotency, so a retry won't create duplicates.
• Most deletes are soft (the row is hidden, not destroyed).
• Every key records a last-used timestamp and IP; API usage is traceable to the key.

Keep control

• Revoke instantly — remove a key from Settings → API Keys and it stops working immediately.
• Expire keys — set an expiry for agents that only need temporary access.
• Separate keys per agent — one key per assistant makes it easy to see who did what and to revoke just one.
• Use test keys while evaluating a new agent or workflow.

A safe first session

1. Generate a read-only key.
2. Ask the agent to read and summarise — orders this week, low-stock items, a doc lookup.
3. Only once you trust its behaviour, issue a scoped read-write key for the specific task.