Security
Read-only by design
orgadmin.ai was built around one rule: exploring your org must never be able to break it. Not by policy or prompt — by architecture.
The guarantees
Each of these is a property of the code, not a promise in a policy.
Mutation methods don’t exist
The Salesforce 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.
Destructive verbs are refused
A single internal request method hard-blocks HTTP PATCH, PUT, and DELETE, and permits POST only for an explicit allowlist of read, query, and retrieve endpoints.
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 for that connection.
When writes are enabled
Deployments, data seeding, and table editing are opt-in — and even then, guarded:
- Write features are disabled unless the deployment explicitly sets SALESFORCE_WRITE_ENABLED — browsing-only installs physically cannot write.
- Metadata deployments are owner/admin-only; a production target defaults to a check-only validation, and a real production deploy requires an explicit, per-run confirmation.
- Data seeding refuses production targets outright, and field-level masking is applied before data leaves the source org.
- Data-table edits are validated server-side against each view’s explicit field allowlist.
- OAuth state is a signed, expiring, browser-bound token — CSRF-protected end to end.
What we store — and 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 and AI learnings your team creates
- · AI token usage counts per user
- · The audit log of API calls
Never stored
- · Your Salesforce password — OAuth only, entered on salesforce.com
- · Record data at rest — queries and grids run live and are not persisted
- · Tokens or secrets in logs
- · Your data in AI training sets — providers are called via API under your admin’s configuration
Security questions
Point it at production. That's the point.
Start free and see your whole org documented — safely.