Security architecture

How ACLs evaluate

A user needs to pass the table (row) ACL and the field ACL. Most specific match wins.

1. 1 · table.fielde.g. incident.short_description→
2. 2 · parent.fielde.g. task.short_description→
3. 3 · *.fieldAny table, that field→
4. 4 · table.*e.g. incident.* for every field→
5. 5 · parent.*e.g. task.*→
6. 6 · *.*The catch-all default

ACL rules of thumb

Inside one ACL, roles, condition and script must all pass.

• ✦Roles before scripts. Role and condition checks are cheap; script ACLs run per row and per field.
• ✦Deny-Unless. Newer releases add Allow-If and Deny-Unless ACL types; use Deny-Unless for hard guardrails.Hidden gem
• ✦Query ACLs. Protect against data inference through filters with query_match / query_range operations.Hidden gem
• ✦Before-query BRs. Use them to hide rows at scale (e.g. by company), and ACLs to protect fields.
• ✦Scripted REST. Require authentication and an ACL on every resource; never "no auth" in prod.
• ✦Debug Security. Session Debug → Security shows exactly which rule allowed or blocked access.

Platform security checklist

The baseline a security review will ask about.

• ✦Least privilege. Role design by job function; no admin for integrations or service accounts.
• ✦Integration users. Web service access only, OAuth 2.0 over basic auth, one user per integration.
• ✦Secrets. Credentials and connection aliases; never in properties or scripts.
• ✦Security Center. Track hardening scans and security posture over time.
• ✦MFA & SSO. SSO for users, MFA for admins, local login restricted to break-glass accounts.
• ✦Sub-prod data. Mask personal data on clone; sub-prods are a classic leak path.
• ✦Domain separation. Only for genuine multi-tenant needs (MSPs). It adds complexity to everything.Hidden gem