Skip to main content

Security Model

This page summarizes how aprity protects access to your org and to your documentation.

1. Reading your metadata: JWT Bearer​

aprity reads your org's metadata with the OAuth 2.0 JWT Bearer flow:

  1. The aprity service builds a short-lived assertion for your integration user and signs it with aprity's private key, held in a key vault.
  2. Salesforce checks the signature against the aprity certificate in your External Client App.
  3. If it matches, Salesforce issues an access token, which aprity uses to read metadata.

What this means for you:

  • No password is stored, and no user has to be signed in for an analysis to run.
  • You stay in control: disabling the External Client App stops all access immediately.
  • Read-only: aprity reads metadata. It does not create, update or delete records in your org.
  • Identity check: aprity checks that the org answering is the org that was registered, and refuses the connection otherwise.

2. Calls from the package: signed requests​

Every call from the aprity package to the aprity service is signed with HMAC-SHA256, using a secret issued to your installation at registration:

  • the secret is stored in a protected setting that org admins and custom Apex cannot read;
  • the aprity service rejects any request whose signature does not match;
  • signed requests carry a timestamp, so a captured request cannot be replayed later;
  • the package checks the current org ID before signing, so a sandbox copy cannot use the source org's secret (see Sandbox refresh).

3. Signing in to the web portal and AI clients​

  • Users sign in to the portal with Salesforce single sign-on (OAuth authorization code with PKCE), through your External Client App.
  • After sign-in, aprity checks the user's aprity permission sets in your org to decide whether they are a reader or an administrator. A user with neither is refused.
  • AI clients (ChatGPT, Claude, Cursor, GitHub Copilot) connect to the Remote MCP server with OAuth 2.1 and PKCE, through the same Salesforce login. Users never copy a token.
  • Only the profiles you allow in the External Client App policies can sign in to either.

4. Data isolation​

  • Each customer is a separate tenant. Every stored item carries its tenant, and every read is scoped to it.
  • Within a tenant, data is further scoped by org.
  • A portal session only serves the org it was opened for.

5. Hosting and encryption​

  • aprity runs on Microsoft Azure. Organizations on the default environment are hosted in Europe (France).
  • Data at rest is encrypted by the Azure platform; secrets and signing keys are kept in Azure Key Vault.
  • All traffic uses HTTPS.
  • AI models are hosted on Microsoft Azure. See Data Residency and Privacy for where AI processing happens.

What aprity reads, and what it does not​

  • aprity reads metadata and configuration: objects, fields, validation rules, flows, Apex, profiles and permission sets, record types, OmniStudio components, and the records of custom metadata types and custom settings, which often hold business configuration.
  • It does not read your transactional business records (accounts, opportunities, contacts and so on).
  • Raw metadata retrieved during an analysis is deleted when the analysis ends; aprity keeps the documentation and analyses built from it.