Storacle Security Standards

How Storacle handles data and security inside the Salesforce org it is installed in.

Last updated: October 16, 2026

1. Purpose and Scope

Storacle is a managed package application for Salesforce, built by Syndacon and distributed through the AgentExchange. This document describes how Storacle handles data and security inside the Salesforce org it is installed in.

It is the product-specific companion to the Syndacon Security Standards, which cover how Syndacon itself operates: organizational security, the secure development lifecycle, vulnerability management, incident response, and data protection across all Syndacon products and services. Together, the two documents form the complete security picture for Storacle.

Questions and security reports can be sent to security@syndacon.com.

2. Your Data Stays in Your Org, and Is Never Read

This is the most important property of Storacle's design: your business data is not just safe from Storacle. It is never read, never modified, and never transmitted by Storacle at all.

  • Storacle runs entirely within your Salesforce org. Syndacon runs no servers, services, or databases that hold your Salesforce data. None of your Salesforce data leaves your org.
  • Storacle never reads the contents of your records. The product measures storage: it works with aggregate numbers (record counts and storage usage) and with org metadata (which objects exist and how they are configured). The field values inside your business records are never queried, inspected, or processed.
  • Storacle never modifies your records. It creates and manages only its own packaged records; it performs no writes of any kind against your business data.
  • Storacle's own records live in your org, under your control. The data Storacle does create (snapshots, measurements, alerts, and logs) consists of ordinary records in your org, visible to and administrable by your administrators like any other data, and subject to your org's own security model.

3. No Syndacon Access to Your Org

Exactly this much passes between your org and Syndacon, and nothing else:

  • Two counts, out to Syndacon. After each nightly engine run, Storacle writes AssignedSeats (how many people on Storacle's user list hold a seat) and SuccessfulRunsLast30Days (how many engine runs completed in the last 30 days). Salesforce delivers them to Syndacon's License Management Org through the Feature Management App, Salesforce's standard licensing tool for AgentExchange partners. That org is the only place they can be read. We use them to keep licensing accurate and to understand the health of the Storacle engine in each customer org, so we can support it.
  • Your org ID and one email address, out to Stripe, only at purchase. When someone clicks to purchase seats, the checkout link carries your org ID and that person's email address to Stripe, so the payment reaches the right org. Nothing goes to Stripe until someone clicks.
  • Five licensing values, in from Syndacon. Syndacon pushes LicensedSeats, TrialExpiration, RenewalDate, SeatsRemovedAtRenewal, and SubscriptionState into your org through the Feature Management App, Salesforce's standard licensing tool for AgentExchange partners. They set what your org is entitled to, and that is all they can do.

None of these carries your Salesforce data.

  • Storacle gives Syndacon no access to your org. The product contains no remote-administration capability. Nothing in Storacle lets Syndacon sign in to, read from, or act in an org where it is installed. The only way in is Salesforce's own: you can grant Syndacon login access for support, as described below. Salesforce provides and controls that access, not Storacle.
  • The billing portal checks who is asking. Before it opens your org's billing, its sign-in proves that the person belongs to your org and holds Storacle's billing permission.
  • Support works by invitation only. If you want Syndacon's help inside your org, access happens exclusively through Salesforce's own grant-login mechanism: explicitly granted by you, scoped by Salesforce, time-limited, and revocable by you at any time.

4. Callouts and Credentials

  • The only callouts Storacle makes are to your own org's Salesforce APIs. Storacle calls Salesforce's APIs on your org itself to gather the record counts and storage statistics it reports on. It makes no callouts to any external endpoint.
  • Storacle creates, stores, and rotates no credential in your org. The nightly job reads your org's own record counts with the session the platform gives it, so there is no stored secret to protect or expire. The package holds no Stripe secret and never calls Stripe.

5. Built on the Platform Security Model

Storacle is developed to Salesforce's security model and secure-coding requirements, as detailed in the Syndacon Security Standards, §4. Salesforce and AgentExchange Standards:

  • Object- and field-level security and sharing rules are enforced in Apex; the code declares its sharing model explicitly.
  • SOQL uses bind variables; dynamic query construction from untrusted input is prohibited.
  • Lightning Web Components follow the platform's Lightning Web Security model, with Salesforce's LWC security lint rules enforced on all component code.
  • No record IDs, org IDs, usernames, endpoints, or secrets are hardcoded.
  • Access to Storacle's features and records inside your org is governed by permission sets you assign. Your administrators decide who can see and do what.

6. Release Integrity and Security Review

Before it is packaged, every Storacle release passes the full validation pipeline described in the Syndacon Security Standards, §3. Secure Development Lifecycle: layered code review, static security analysis, and test suites that run under non-administrator user contexts. Promotion of a release is a human-approved step, and the product is submitted to the Salesforce AgentExchange security review, with re-submission as required for material changes.

7. Reporting and Review of These Standards

Suspected vulnerabilities in Storacle can be reported to security@syndacon.com; the Syndacon Security Standards, §5. Vulnerability Management describe how reports are handled. This document is reviewed at least annually, and whenever the product or platform requirements change materially. The "Last updated" date above reflects the most recent revision.