Data Security in REDA AI

Data security is a core design principle of REDA AI. This article explains exactly how REDA AI handles your Salesforce data, what is sent to the AI service, what is stored and where, and the controls available to keep your data protected.

What Data Does REDA AI Send to the AI Service?

In both funding models, requests travel from Salesforce to the AI provider for processing. They may contain messages, prompts, selected record context, tool results and document content needed for the task. Data sent for processing leaves Salesforce. Governance of Salesforce access does not replace the provider’s own processing, retention or contractual terms.

With Bring your own AI, review the terms of each connected provider and model. Provider API keys are stored in your organisation’s Salesforce credential store, not in agent prompts or a REDA-hosted credential store. Named Credential callout settings and External Credential Principal Access determine who can use a connection. Agents may use their selected connection; admin AI features and document processing use the organisation default. Review both routes when approving providers.

With AI included, Processing Tier and the REDA agreement govern processing. Economy has its own consent and endpoint requirements. These managed-tier rules do not describe the customer-account model. See the setup and access steps.

Where your data is held

Conversation records, messages, usage records and logs are held in your Salesforce organisation under its access and retention settings. AI requests go directly to the provider; REDA does not operate an intermediary store for those requests. Provider retention, training use and residency depend on the applicable provider agreement and account configuration. In Bring your own AI, those are your direct provider terms; do not assume REDA’s AI-included arrangements extend to that account.

What is Stored in Your Salesforce Org?

The following records are created within your Salesforce org and remain under your full control:

Data Retention & Archival

Conversation and message records accumulate over time. REDA AI includes an automated archival process, run at 2:00 AM on the 1st of each month, that deletes conversations, messages and credit transactions once they pass their retention window. Retention is set globally in Platform Settings and can be overridden per agent, subject to a 60-day minimum; an agent with Skip Archival ticked is never archived. Setting the global value to 0 disables archival entirely.

Archival activity is tracked in AI Archival Log records which carry the run’s counts and totals plus CSV attachments listing the deleted conversations, messages and credit transactions. Read them together with the log’s Error Details field, which is where REDA AI notes any CSV that hit its 50,000-row cap. See AI Archival Logs.

Salesforce Security Model

REDA AI operates entirely within the Salesforce security model. This means:

• Field-Level Security (FLS) is respected — if a user does not have read access to a Salesforce field, the agent cannot see that field’s value. Every packaged tool query runs in Salesforce’s user mode, and a call that arrives without an enforcement level is treated as user mode, never as elevated.
• Record sharing rules apply — if a user cannot see a record in Salesforce, the agent cannot retrieve or reference it for that user.
• Permission sets control who can use the agent — only users with the appropriate REDA AI permission set assigned can interact with the AI.

The one exception: Execution Context

An Agent Definition has an Execution Context field. Set to System, that agent’s tools read fields the running user cannot. It is deliberately hard to reach:

• Both conditions are required — Execution Context must be System and the agent’s Channel must be API. An internal, community or external-widget agent cannot be elevated. Execution Context is a restricted, dependent picklist, so Salesforce itself rejects the illegal combination when the record is saved — and REDA AI refuses to elevate regardless.
• Sharing is never widened. Elevation covers object and field permissions only. Record visibility is enforced at the class level, so an elevated agent reads more fields on records it could already see — it can never reach a record the running user could not.
• A prompt can never cause it. The enforcement level comes from the admin’s saved configuration and nothing else. It is never derived from the model’s tool arguments, the user’s message, record content, an uploaded file or an inbound email — so no injected instruction can talk an agent into elevating itself.

If you have not set Execution Context to System on an API agent, every statement above this section holds without qualification.

External Widget & API Key Security

If you deploy the External Widget channel on a public website, the widget is secured by an API key that is unique to each agent. This key is:

• Generated by the admin within the REDA AI app.
• Shown only once at the point of generation — it cannot be retrieved again. Store it securely immediately.
• Never stored at all, in any recoverable form. The Agent Definition keeps a one-way SHA-256 hash with a random per-record salt; the key itself is never written to your org. That is why a lost key cannot be recovered by anyone, including REDA — it is not hidden, it is not there.
• Revocable at any time — if a key is compromised, you can revoke it immediately and generate a new one.

You can also configure an Allowed Origins list on the agent definition, so the widget only accepts requests from specific website domains you control.

For full API key management guidance, see API Key Management.

Connect selected agents through MCP

MCP connects an approved AI assistant to selected active Internal agents. Each person signs in with their Salesforce identity. The host receives agent entry points; individual REDA tool and prompt definitions are not exposed as separate MCP tools. Configure a Salesforce Site, an External Client App, both REDA AI User and REDA AI MCP User assignments, and agent opt-in. See the administrator setup guide and user guide. Interaction data can reach the connected host and configured AI providers as well as Salesforce. Review the intended data and agreements; this is not a promise that data never leaves Salesforce.

Understand the Economy credit change

Economy ordinary usage now applies a 0.40 multiplier to the base credit rate. For unchanged token quantities and base rates, an example costing 100 base credits costs 40 Economy credits. At the previous 0.10 multiplier it cost 10: the new debit is four times the previous Economy debit, and 60% below base. This changes credit consumption, not the subscription price. File pre-extraction is charged separately at full rate. A provider fallback can use a different effective tier; inspect the actual transaction rather than applying 0.40 to every mixed operation. New credit transactions record Processing Tier; historical rows are not backfilled. Economy still requires consent and compatible licence/provider configuration; a missing consent is refused, not silently processed at another tier.

Frequently Asked Questions