OrgGeniusSecurity
It can't show you what you couldn't open yourself.
That isn't a policy the assistant is asked to follow. It is the platform enforcing it, on every query, before a single row reaches the model. This page is the whole story, including the parts we would rather you heard from us.
What leaves the org
Two parties. No third.
The API key lives in an External Credential your admin creates in your own org. Every callout goes from your org to your own account with your model vendor. We are not a subprocessor; the retention and training terms are the ones in the contract you already hold.
Your Salesforce org
OrgGenius runs here, as a managed package.
- Every query
WITH USER_MODE - Masking applied before anything is sent
- Audit log written here
- Key held in an External Credential
Your model vendor
Anthropic, OpenAI or Azure OpenAI — your account.
- Receives the question and masked tool results
- Returns text or a tool call
- Your retention terms apply
OrgGenius servers
There aren't any in the path. No index, no cache, no copy, no telemetry. The only thing that reaches us is what you choose to email.
What is sent on every request
| Sent | Contains your data? |
|---|---|
| The system prompt | No. Ships as a static resource, identical in every org. |
| Tool definitions — names, descriptions, parameter schemas | No. Metadata, not records. |
| The user's question | Yes — whatever they typed. |
| Tool results | Yes. The records the query returned, field by field, after masking. Only a tool the model actually calls sends records. |
| Conversation history for the current question | Yes — the above again, on each turn up to the turn cap. |
A question answered without retrieval sends no CRM data at all. A question that retrieves nothing sends nothing. Every tool's exact field list is documented — ask for the data-flow report.
Permissions
Agents don't use the UI. Neither does this one — which is the point.
Salesforce is API-first. Every page and every Flow sits on top of an API surface an authenticated user can reach directly, and an AI agent reads that API and does whatever it allows. Anything enforced only in the UI is invisible to it.
OrgGenius is built on the opposite premise. All 90 tools go through one code path that runs WITH USER_MODE, so the enforcement is the sharing model itself — object permissions, field-level security and record sharing, applied by the platform on every query. There is no service account, no privileged mode, and no way to phrase a question that reaches a record its asker cannot open.
And because the assistant can read the permission model, it is also how an admin finds the gap first: “who can see this, and why?” is a question it answers in one pass.
Masking
Permissions decide which records. Masking decides which values.
They are different questions. A user may be entitled to see a card number in Salesforce and you may still not want it sent to a model vendor. Masking is configured per org, point-and-click, in three layers:
- Named fields —
Contact.SSN__c, or a bare field name to catch it on every object - Patterns — a library for national ID, card number, email and phone, plus your own regular expressions
- Blocked terms — codenames, for the deal nobody outside the room should be able to name
A try-it box tests a rule before it is saved. When a value is withheld the assistant is told it was withheld, so it says the value is masked rather than pretending the data does not exist. Your own people still see everything they are entitled to — masking is about what crosses the boundary, not about hiding data from your team.
Honest limit: masking covers text values and files read as text. It cannot see inside a PDF or an image. Switch the attached-file tool off if that matters in your org.
![The masking settings: two masked fields, pattern library with payment cards and phone numbers ticked, a blocked term, and the try-it box showing a pasted sentence with the card number, codename and phone number replaced by [redacted].](/img/security-masking.webp)
Injection defence
CRM free-text fields are user-controlled input flowing into a tool-calling model. Every result is scanned in Apex — deterministically, not by asking the model to notice — for text addressed to the assistant rather than about the business. Findings ride beside the rows, are reported to the person by record name, and are never obeyed. The eval suite gates this at 100%.
The posture, live
Walk your security team down this list.
The settings Overview reads the org's actual state — how many tools, whether actions are on, what is masked, who holds which permission set, how many audit entries exist and how long they are kept. It is written in the order a reviewer asks the questions.
Seven permission sets, layered
User · Admin · User Support · Actions · Email Customers · Knowledge · Agent Builder. Every capability beyond asking needs its own permission on top. A help desk can see why somebody is locked out without also surveying the org's whole permission model.
Everything is on the record
Every question, every tool call and every proposed action — including the declined ones — is written to an audit object inside your org. Retention is a setting; a nightly job deletes past the window and empties the Recycle Bin, so the deletion is real rather than a fifteen-day reprieve.
Tested
Gates, not scores.
The model is nondeterministic, so one clean run is a sample, not evidence. The evaluation harness runs 97 questions in buckets with hard acceptance gates, and the number we report is from the 29 questions the prompts were never tuned against.
| Bucket | Gate | What it proves |
|---|---|---|
| Out of scope | 100% abstention | Questions the org cannot answer get “I don't have that in the Org,” not an invention |
| Permission | 100% empty | A user without access gets nothing — and no hint of what exists beyond their access |
| Injection | 100% reported | Instructions planted in record text are surfaced to the person, never obeyed |
| In scope · Ambiguity | Scored | Correct, cited answers; sensible clarifying questions |
Enforcement itself is tested separately, in Apex, with System.runAs against a genuinely low-privilege user — not by asserting the query string. 531 tests, 40 test classes.
Where it stands
Built for the security review. Not yet through it.
OrgGenius is not yet listed on the AppExchange and has not yet completed Salesforce's security review. It is built against those requirements — no hardcoded secrets, Named Credentials only, every query in user mode, no without sharing anywhere — and beta installs are direct until it passes. If your security team wants the data-flow report, the eval results, or a walkthrough of the Overview against your own org, ask.