Security & Privacy — RGA for Salesforce

For the CISO, CIO, and security team evaluating Revenue Growth Agent (RGA) for use with Salesforce. This page is the Salesforce-specific deep dive. For the platform-wide controls, retention, residency, and sub-processor list, see the Trust & Security Center. For a long-form walkthrough that reads start to finish, see the CISO's technical guide to securing RGA in Salesforce.

Security isn't a feature we bolted on. RGA's architecture, daily engineering workflow, and operational controls are built around the controls that frameworks like SOC 2 and GDPR require. A formal SOC 2 audit is on our near-term roadmap; in the meantime this page describes precisely how your Salesforce data and credentials are protected so you can evaluate the engineering directly.

Security principles

1. Your credentials stay yours. RGA staff never see your Salesforce private key in plaintext, not even during setup. The key is generated client-side and never returned in plaintext by any API.
2. Defense in depth. Sensitive data is protected by multiple independent layers, so compromising any single system is not enough to expose it. The most important layer is key separation: ciphertext and master key live in different systems.
3. Org-ownership verified before storage. RGA does not trust a submitted credential. It exchanges the credential for an access token against Salesforce and confirms the returned organization ID matches the connecting admin's claim before persisting anything.
4. Least privilege and tenant isolation. Every request is authenticated and scoped to the caller's organization. No customer's data or credentials are reachable by another customer's traffic.
5. No training on your data. Your Salesforce data is processed to generate prep, discovery, and proposal outputs. It is never used to train AI models.

Two ways to connect, one security model

A Salesforce administrator can connect their org to RGA in either of two places. Both use the same authentication architecture (OAuth 2.0 JWT-Bearer against an External Client App you create and own), and the same credential-protection architecture (AES-256-GCM with key separation). The only difference is where the admin sits while doing it.

A. From the RGA web app (Settings → Integrations)

The admin signs into the RGA web app, opens Settings → Integrations, and runs a self-serve connect flow:

• RGA generates the X.509 certificate and private-key pair in the browser, using a vetted JavaScript cryptography library. The private key is held only in the admin's browser memory until they submit it on the final step.
• The admin uploads the certificate file to their Salesforce External Client App.
• The admin pastes the certificate's consumer key into RGA's form, and the private key never leaves the browser memory until it is submitted over TLS to RGA's backend on the final step.
• RGA validates the credential against Salesforce before storing it (see below).

B. From inside Salesforce (Lightning component)

The admin opens the RGA Meeting Prepper Lightning Web Component on any record and clicks the connection gear. The same credential form loads in an iframe served from RGA's own domain, isolated from the Salesforce Lightning page by the browser's Same-Origin Policy. The Salesforce page cannot read what the admin types into the form, and the iframe cannot read the Salesforce page. The same in-browser key generation, same validation, same encrypted storage.

Both paths produce the same encrypted credential in the same database column, protected by the same key.

Authentication and authorization

How the embedded component authenticates

The RGA Meeting Prepper is a Lightning Web Component that wraps an iframe served from RGA's domain. When a rep opens it:

• Your Salesforce org mints a short-lived, HS256-signed token carrying the user, org, and record context.
• That token is exchanged with RGA's backend over an encrypted handshake that sets an HttpOnly, Secure, SameSite=None session cookie. The token never appears in a URL or in server access logs.
• Because the iframe is served from RGA's domain, the Salesforce Lightning page cannot read its contents, and the iframe cannot read the Lightning page. The browser's Same-Origin Policy enforces this boundary.

How RGA authenticates to your Salesforce org

RGA uses the OAuth 2.0 JWT-Bearer flow against an External Client App (ECA) that you create and control in your own org. The ECA is Salesforce's modern successor to Connected Apps and the integration pattern Salesforce now recommends.

• The assertion is certificate-signed, so there is no shared client secret that could leak from either side.
• The flow issues no long-lived refresh tokens. Each access token is minted on demand from your certificate and is short-lived, so there is no standing credential to steal or replay.
• Access is governed by the permissions on the dedicated integration user you provision and scope.
• Reads and writes attribute to the calling user where Salesforce permits it. In cases where a Lightning-context session is not accepted by the Salesforce REST API (a known Salesforce limitation), RGA falls back to the integration user. We disclose this plainly: those specific writes are attributed to the integration user in your Salesforce field history.

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 Salesforce org and carried in the signed token; RGA re-enforces it server-side. Standard users can run meeting prep but cannot view or alter the connection.

Credential protection

When your admin connects the org, the Salesforce private key is handled as follows:

In transit

Submitted over TLS 1.3 to RGA's backend, inside an iframe isolated from the Salesforce DOM. The key never enters the Salesforce page, a URL, or a server access log.

Validated and ownership-verified before stored

RGA does not just check that a credential parses. It mints a real JWT-Bearer access token against your org with the submitted key, then verifies the returned organization ID matches the connecting admin's claim. Only then is the credential persisted. Three things this rules out:

• A typo'd or broken key (rejected on the spot).
• A key for a different org than the admin is logged into (rejected — prevents cross-org binding mistakes).
• A maliciously crafted submission that doesn't actually authenticate (rejected — there is no path to persistence without a real Salesforce token round-trip).

Encrypted at rest with authenticated encryption

The private key is encrypted with AES-256-GCM (authenticated encryption, NIST SP 800-38D) before it is written to RGA's database.

Key separation across two trust boundaries

This is the control that matters most.

An attacker would have to compromise both systems to recover a single plaintext private key. Compromising the database alone yields only ciphertext.

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 and audit

Credentials are scoped to your Salesforce org by a verified org identifier. Cached access tokens are keyed per-org and expire on a short timer. Who set or changed the credentials and when is recorded, backed by immutable row-level change history in the underlying database.

Data security

• In transit: all communication uses HTTPS/TLS.
• What RGA reads: the Salesforce record fields needed to prepare for a meeting — standard business-contact fields (name, title, company, contact details) and the RGA-managed custom fields it writes results back to.
• What RGA stores: prep inputs and outputs needed to render and share the briefing, associated with your account.
• AI processing: your data is processed to generate prep, discovery, and proposal outputs. It is never used to train AI models. Configuration evidence for the no-training terms with our AI providers is available on request.

Privacy and compliance

The policies below apply uniformly across the entire RGA platform; the Salesforce integration inherits them.

• Framework alignment. RGA's architecture and operational controls are built around SOC 2 and GDPR principles. A formal SOC 2 audit is on our near-term roadmap; we will publish the report when it is complete. In the meantime, the controls on this page are implemented and verifiable today.
• Controller and processor. Under GDPR, you (the customer) are the Data Controller and RGA is the Data Processor, handling data on your behalf.
• Data subject requests. Access, export, correction, deletion, and the right to be forgotten are honored within 30 days. Email support@revenuegrowthagent.com.
• Data Processing Agreement. A DPA is available on request for customers who require contractual data-protection commitments.
• Data retention. All customer data — account information, CRM data, transcripts, and uploaded content — is retained for 90 days after cancellation, then permanently deleted. Earlier deletion on request.
• Data residency. Customer data is stored and processed primarily in the United States, on infrastructure operated by US-based providers. If you are located outside the United States, your data is transferred to and processed in the United States under appropriate safeguards including Standard Contractual Clauses (SCCs).
• Sub-processors. See the published sub-processor list, kept current.
• Privacy Policy. See the Revenue Growth Agent Privacy Policy.

Note for the security reviewer: this page describes the controls we actually run today rather than a certification we have not yet completed. If your evaluation needs specific documentation (a security questionnaire, data flow diagram, incident response plan, or DPA), email support@revenuegrowthagent.com and we'll respond.

Network security

• The integration communicates only between your Salesforce org and RGA's platform over HTTPS.
• The iframe origins are explicitly allowlisted as Trusted Sites in your Salesforce org during setup, so the component cannot load arbitrary third-party content.
• RGA's apex domain (revenuegrowthagent.com) and the www host both serve the API directly without redirect, so the Salesforce LWC's CORS preflight resolves on the same host that ultimately serves the API call — no preflight failure mode.

Standing platform security posture

Beyond the Salesforce integration, the RGA platform maintains:

• Authenticated APIs. Every API route requires a valid token; there are no unauthenticated data endpoints.
• Multi-tenant authorization. Every data endpoint verifies the caller's organization before returning or modifying data, by a verified organization identifier.
• Independent security scanning. The platform has been scanned with OWASP ZAP with zero high- or medium-severity findings.
• Injection prevention. All database query inputs are sanitized.
• Rate limiting on authentication, API, and upload paths.
• Security headers. Content-Security-Policy, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy.
• Error sanitization. Client-facing errors never expose stack traces, file paths, or personal data.
• MFA on internal access to every system holding customer data or tokens, via authenticator app or SSO with 2FA enforced.

Audit, monitoring, and incident response

• Credential changes are recorded with the responsible identity and timestamp, backed by immutable change history.
• Platform request logs capture API access for the platform's retention window.
• A documented incident response plan exists: detect, contain, assess, notify affected customers, remediate, and conduct a post-incident review. The incident owner is the RGA founder/CEO; the intake channel is support@revenuegrowthagent.com. The full plan is available on request.
• Breach notification. Affected customers are notified without undue delay and within 72 hours of confirming a breach.
• To report a suspected vulnerability or incident, email support@revenuegrowthagent.com.

How to evaluate this in 30 minutes

If you want to validate the controls above rather than take them on faith:

1. Inspect the ECA in your own org. You created it — review its scopes and the integration user's permission set. Tighten to your comfort level.
2. Confirm there's no refresh token. The JWT-Bearer flow doesn't issue one. Verify in your org's connected-app usage.
3. Test revocation. Disable the ECA and confirm the integration stops. You hold the kill switch.
4. Test org-ownership verification. Submit a credential from a different org and confirm RGA rejects it before persistence.
5. Request the docs. Ask for the data flow diagram, incident response plan, and a DPA. We maintain all three.

Contact

Security, privacy, and compliance questions, or to request a DPA, security questionnaire, data flow diagram, or incident response plan: support@revenuegrowthagent.com