Bringing Revenue Growth Agent Into Salesforce, Without Compromising Your Security
A technical guide for the CISO of a small or mid-sized enterprise. No shared secret. No refresh token. Credentials encrypted under two independent locks. Your data is never used to train AI.
Reading time: ~8 minutes
The 60-second answer
If you read one section, read this one.
Revenue Growth Agent connects to your Salesforce org using the modern, Salesforce-recommended OAuth 2.0 JWT-Bearer flow against an External Client App that you create and control. There is no shared client secret and no long-lived refresh token for an attacker to steal. Every access token is minted on demand from a certificate, is short-lived, and is governed by the permissions on an integration user you define.
The private key that signs those tokens is encrypted at rest with AES-256-GCM, and the master encryption key lives in a completely separate system from the database that holds the ciphertext. Compromising either one alone yields nothing useful. No RGA staff member can retrieve your private key in plaintext through any API path.
The data RGA processes is never used to train AI models. The Meeting Prepper builds its research from publicly available sources plus the standard business-contact fields on the record, not your confidential internal data.
We run the controls and processes a SOC 2 audit examines, and we operate against that program today while we work toward formal attestation. This article describes exactly how those controls work, so your team can evaluate the engineering directly.
Why a CISO is right to ask hard questions
Your CRM is one of the highest-value data assets you own. Bolting an AI integration onto it can introduce three classic risks at once. A good architecture answers all three before you're forced to ask.
A stored secret or refresh token that, if leaked, grants ongoing access to your org.
An integration that can read and write far more than it actually needs.
A vendor that won't tell you where your data goes, or whether it trains a model.
1. How RGA authenticates to your Salesforce org
RGA uses the OAuth 2.0 JWT-Bearer flow against an External Client App (ECA) — the modern successor to Connected Apps and the integration pattern Salesforce now recommends.
- ✓You create and own the app. The ECA lives in your org. You configure it, scope it, and can revoke it at any time from Salesforce Setup without involving RGA.
- ✓The assertion is certificate-signed. There is no shared client secret that could leak from either side.
- ✓There are no long-lived refresh tokens. Each access token is minted on demand and expires on a short timer. There is no standing credential sitting in our database waiting to be replayed.
- ✓Access is governed by an integration user you provision and scope. A dedicated integration user, with the object and field permissions you grant it, performs RGA's reads and writes. Those writes attribute to that user in your Salesforce field history, so every change RGA makes is traceable to one account you control and can revoke.
The CISO takeaway: there is no secret to rotate on our side and no standing token to steal. If you ever decide to move away from RGA, you disable one app in your own org and the integration stops immediately.
2. How RGA stores your private key
When your Salesforce administrator connects the org, they paste the ECA's private key into RGA's settings form. Here is the full lifecycle of that key, end to end.
In transit
The key is submitted over TLS 1.3. The settings form lives inside an iframe served from RGA's own domain, not the Salesforce Lightning page. Because of the browser's Same-Origin Policy, the Salesforce page cannot read that iframe — the private key never enters Salesforce's DOM tree, a URL, or a server log.
Validated before it is ever stored
RGA constructs a real JWT-Bearer assertion with the submitted key and exchanges it for an access token against Salesforce. Only if Salesforce returns a valid token is the credential stored. Broken credentials are rejected on the spot.
Encrypted at rest with authenticated encryption
| Property | Value | Why it matters |
|---|---|---|
| Algorithm | AES-256-GCM (NIST SP 800-38D) | Confidentiality and integrity |
| Key length | 256 bits | Brute force is infeasible |
| Initialization vector | 96 bits, random per encryption | Same plaintext never yields the same ciphertext |
| Authentication tag | 128 bits, verified on decrypt | Any tampering fails decryption |
| Format | Versioned (v1:<iv>:<ct>:<tag>) | Future algorithm migration without breakage |
Key separation across two trust boundaries
This is the control that matters most.
| Component | Where it lives | What you'd get by compromising it alone |
|---|---|---|
| Encrypted private key (ciphertext) | RGA's database | Opaque ciphertext. Useless. |
| Master encryption key | RGA's serverless platform environment (separate system) | A key with no data to decrypt |
An attacker would have to compromise both systems to recover a single plaintext private key. This is defense in depth in its most literal form.
Write-only, by design
There is no API path that returns a stored private key in plaintext — not to RGA staff, not to the admin who entered it. To rotate, you generate a new certificate in Salesforce and re-submit; the old encrypted value is overwritten and the cached access token is invalidated immediately.
Per-tenant isolation & audit
Credentials are scoped to your org by a verified org identifier; one customer's traffic can never reach another's. Who set the credentials and when is recorded, backed by immutable, row-level change history.
The CISO takeaway: even in a worst-case partial breach, your private key stays confidential. The design assumes a system will eventually be compromised, and ensures one system is never enough.
3. How the embedded component is isolated in the browser
The RGA Meeting Prepper is a Lightning Web Component that wraps an iframe served from RGA's domain. When a rep opens it:
- ✓Your org mints a short-lived, HS256-signed token carrying the user, org, and record context.
- ✓That token is exchanged over an encrypted handshake that sets an HttpOnly, Secure, SameSite=None session cookie. It never appears in a URL or log.
- ✓The Salesforce page cannot read the iframe, and the iframe cannot read the Salesforce page. A cross-site-scripting flaw on the Lightning page cannot reach the credential form, and vice versa.
Administrative gating: only a Salesforce administrator (Modify All Data or Customize Application) can connect your org or change its credentials. Administrative status is computed inside your org and re-enforced server-side by RGA. Standard users can run prep but cannot view or alter the connection.
4. What data RGA touches — and whether it trains AI
The Meeting Prepper's intelligence comes from publicly available research sources — the prospect's company website, public professional profiles, recent news, and industry data. To know who to research, it reads a defined set of standard business-contact fields on the record: First Name, Last Name, Email, Phone, Company Name, Title, Company Website, Industry, Company Size, and an optional LinkedIn profile URL.
Those business-contact fields are personal data under GDPR, even though they are low-sensitivity. Here is exactly what that means in scope:
The Meeting Prepper enriches a prospect from publicly available sources plus the standard business-contact fields listed above. It does not read your confidential internal data — product roadmaps, internal strategy, or trade secrets — and nothing it processes is used to train AI models.
Data flow at a glance
Salesforce (your org)
| short-lived HS256 token + standard contact fields
v
RGA backend (serverless, TLS) -- mints SF access token on demand
| from your AES-256-GCM-encrypted key
+--> Public research sources (web, professional profiles, news)
+--> AI processing (no training on your data)
v
Prep output --> rendered in the in-Salesforce component
+-> written back to RGA custom fields on the record5. The platform underneath: standing security posture
6. Privacy, compliance, and where we stand on SOC 2
We run a defined controls program today and are building toward formal attestation. Here is precisely where that stands.
- •SOC 2 program. RGA's architecture and operational controls are built and run against SOC 2 and GDPR requirements. The controls described here are implemented and verifiable today; formal SOC 2 attestation is on our near-term roadmap.
- •Controller and processor. Under GDPR, you are the Data Controller and RGA is the Data Processor.
- •Data subject requests — access, export, correction, deletion, the right to be forgotten — honored within 30 days.
- •A DPA is available on request for customers who require contractual data-protection commitments.
- •Data retention. All customer data is retained for 90 days after cancellation, then permanently deleted. Earlier deletion on request.
- •Operational controls. Access to systems holding customer data requires SSO + 2FA, is reviewed periodically, and is revoked on off-boarding. Secrets are stored in the platform environment (never in source code), scoped to least privilege, and rotated in response to any suspected exposure. The master encryption key can be rotated without service disruption.
Need a security questionnaire, data flow diagram, or sub-processor list? Email support@revenuegrowthagent.com and we'll respond.
A threat model, stated plainly
A complete threat model names what a design protects against and what it does not. Here is both.
What this design protects against
| Threat | Mitigation |
|---|---|
| Stolen database | Application-layer AES-256-GCM on top of the database's own at-rest encryption — ciphertext only |
| Compromised database API token | Application-layer encryption — token alone yields only ciphertext |
| Compromised platform deploy without DB access | Master key alone is useless without ciphertext |
| An RGA engineer browsing the database | The credential column reveals only ciphertext |
| XSS on the Salesforce Lightning page | Iframe origin isolation — Lightning's DOM cannot read the RGA component |
| Replay of a stolen access token | Tokens cached server-side only, never exposed to the browser; short TTL |
| Cross-tenant access | Every operation gated on a verified org identifier |
What it does not, by design, protect against
| Threat | Why | What backs it up |
|---|---|---|
| Compromise of both the database and the master key | Encryption is intentionally broken only when both halves are owned | SSO + 2FA, audit logging, least privilege, separation of the two secrets across systems |
| Compromise of your own Salesforce admin's session | RGA trusts the token your org issues | Your IdP controls and MFA are the mitigation |
That second row is the honest line in the sand: RGA secures the integration, and your Salesforce identity controls secure the front door. Together they're strong. We'll tell you which half is which.
How to evaluate this in 30 minutes
If you want to validate these claims rather than take them on faith:
You created it — review its scopes and the integration user's permission set. Tighten to your comfort level.
The JWT-Bearer flow doesn't issue one. Verify in your org's connected-app usage.
Disable the ECA and confirm the integration stops. You hold the kill switch.
Ask for the Salesforce security overview, credential-storage posture, and a DPA. We maintain all three.
The bottom line
RGA was designed so that "can we deploy this in Salesforce safely?" is a question you can verify yourself rather than one you have to trust. You own the app, you hold the kill switch, your private key is encrypted under two independent locks, and your data never trains a model. We're candid about the SOC 2 audit still being ahead of us — because a vendor that hides the small caveats is hiding the big ones too.