Atomic CRM Needs an Admin and Row-Level Security Inventory
Atomic CRM is a self-hosted CRM built on a database-backed application model. It stores companies, contacts, deals, notes, and user identities. The first user created in a fresh deployment becomes an administrator, and the project uses row-level security policies to keep records within the intended user and team boundaries.
A bounded ZoomEye query on 15 November 2026 found 0 matches for app="Atomic CRM", 9 for title="Atomic CRM", and 34 for http.body="Atomic CRM" with sub_type=all, page 1, and page size 1. The extremely small counts make broad conclusions unsafe. They do show that exact title matching is a useful discovery clue while an application fingerprint may not be available.
The admin role is a deployment event
The first-user bootstrap is convenient, but it is also a moment when the deployment's authority is established. The owner should confirm who completed that step, disable or remove unused administrators, and review invitations and role changes. An administrator can change application settings that affect every salesperson, so the role should not be treated as an ordinary user with a different menu.
Atomic CRM's database policies are part of the authorization path. The project documentation describes views with security_invoker=on, and a release note records a fix for views that could bypass row-level security. That makes schema review necessary after upgrades. Check whether tenant or team filters exist on the base tables, whether the views preserve them, and whether functions run with the intended security mode.
The API documentation distinguishes a publishable client-side key from a secret server-side key. The publishable key is not an authorization bypass and should respect row-level security. The secret key must stay on the server. If a deployment lets browser code use the secret key to simplify development, the database policy is no longer the only boundary.
Review the record model
Test an administrator, a salesperson, and a user outside the relevant team against the same contact and deal. Check list, search, export, attachment, and note endpoints. A filtered list does not prove that a direct record lookup is filtered. Review database views, API relations, and any agent or automation integration that can read records on behalf of a user.
Inventory the hostname, version, database provider, administrator list, role model, API key type, backup location, and telemetry setting. The exact title count may be tiny, but a CRM concentrates business relationships and pipeline data. The relevant risk is not a large population; it is one improperly scoped record.
