Security
Safe by construction
orgadmin.ai was built around one rule: nothing changes in your org unless you deliberately ask for it. Not by policy or prompt, but by architecture.
The guarantees
Each of these is a property of the code, not a promise in a policy.
Exploring can’t change anything
The client that powers browsing, chat, search, and analytics exposes only read methods. There is no create, update, delete, upsert, or deploy method to call, and an automated test asserts it stays that way.
Each write path is its own narrow client
Writing runs through four separate clients, each restricted to the endpoints its own job needs. The permissions client may only touch permission records; the data client only data-ingest endpoints. A bug in one cannot reach the others.
Credentials encrypted at rest
OAuth refresh tokens and your Connected App secret are encrypted with AES-256-GCM before they touch the database. They are never logged and never sent to the browser.
Tenant isolation on every route
Every request verifies your session, your workspace membership, and that the Salesforce connection belongs to that workspace. No cross-tenant access paths.
Everything is audit-logged
Every Salesforce API call is recorded: workspace, user, connection, API category, method, endpoint, status, and timestamp. Tokens never appear in logs.
Rate limiting everywhere
Per-route, per-user rate limits protect both orgadmin.ai and your org’s API limits from runaway usage.
Your Connected App, your control
Each workspace registers its own Salesforce Connected App, so you control the OAuth scopes, session policies, and can revoke access centrally in Salesforce Setup at any time.
Disconnect means gone
Disconnecting an org revokes the token at Salesforce, deletes the stored secrets, and purges all cached metadata and cached dashboard results for that connection.
How the write paths are gated
Deployments, permission edits, data loading, seeding, and grid editing are opt-in, and even then layered:
- Every write feature is disabled unless the deployment explicitly sets SALESFORCE_WRITE_ENABLED. A browsing-only install physically cannot write.
- Writing needs the “Deploy & write” permission. Owners and admins always have it, members only when an admin grants it, and read-only members never do. Without it, a person can explore everything and change nothing.
- Metadata deployments require an explicit per-run confirmation for a production target, and you can validate first with a check-only run that proves the package works before anything lands.
- Same-org instant saves of Apex and LWC are refused against production; they are a sandbox workflow.
- Record DML is restricted to sandboxes unless an operator separately enables production, a second gate on top of the write switch.
- Data seeding refuses production targets outright, and field-level masking is applied before data leaves the source org.
- Deleting backed-up files needs its own operator switch on top of the write switch, stays locked until the archive has been downloaded, and only ever removes files a finished backup verifiably captured.
- Data-table edits are validated server-side against each view’s explicit field allowlist, so no crafted request can widen it.
- Deployments never delete components that exist only in the target, and every run stores its package.xml manifest and hash.
- OAuth state is a signed, expiring, browser-bound token, CSRF-protected end to end.
What we store, and what we never store
Stored (encrypted where sensitive)
- · Your account (email, name, bcrypt-hashed password)
- · Encrypted OAuth refresh tokens and Connected App secrets
- · Metadata you pull (objects, Apex, flows, etc.) so browsing is fast
- · Org context notes, named KPIs, and AI learnings your team creates
- · Security review and tech debt findings, with their triage state
- · Debug log bodies you pull, so re-reading one costs no API calls
- · A file inventory when you run a scan: names, sizes, and what each file is attached to
- · Duplicate scans: the field values being compared and the pre-merge snapshot that makes undo possible, encrypted with AES-256-GCM under their own key
- · File export archives, temporarily, until their retention window expires
- · Recent dashboard results, briefly: encrypted under their own key, tied to the Salesforce login that read them, kept 15 minutes by default and 24 hours at most, deleted on disconnect, never in backups. Set a dashboard to Always live to keep none
- · AI token usage counts per user
- · The audit log of API calls
Never stored
- · Your Salesforce password (OAuth only, entered on salesforce.com)
- · SOQL console and data grid results: every view re-queries your org live
- · Seeded field values. A run records which masking strategy hit which field, never the values
- · Tokens or secrets in logs
- · Your data in AI training sets: providers are called via API under your admin’s configuration
On SOC 2, plainly
orgadmin.ai is not SOC 2 certified, and we are not pursuing it right now. Certification is an expensive, recurring exercise, and the cost of it lands on the price. Our whole proposition is serious tooling at a price that never needs a business case, and a compliance programme is one of the surest ways to lose that.
We think that is the right call for what this actually is. orgadmin.ai is not a mission-critical system — nothing in your business stops if it is unavailable for an afternoon, because Salesforce remains the system of record and this reads from it. Nor does it hold your key business data: query and grid results are never stored, dashboard results are kept only as short-lived encrypted copies (24 hours at most) so a dashboard does not re-query your org on every open, and what we do keep is metadata, findings and your own notes. The list above is exhaustive.
If your procurement process requires a SOC 2 report, we will not be a fit today, and we would rather you knew that on this page than after three calls. If that changes as the product grows, this section changes with it.
Auditing your own org’s security
This page covers how orgadmin.ai protects your org. To check how well your org protects itself, run the read-only Security Review, compare access in the Permissions Workbench, or work through the 14-point Salesforce security review checklist. What we store and why is set out in the privacy policy.