CDAI Security

1. CDAI Security Overview

CDAI security covers how Allocera Intelligence LLC protects the data that customers connect to the CDAI Engine, our marketing analytics platform that calculates true contribution margin across advertising campaigns. This page describes the protections that are in place today. It should be read together with our Privacy Policy and Terms of Service, and our home page explains what the platform does.

2. Services and Data

The CDAI Engine has three parts, and CDAI security applies to all of them.

• Client portal: the web application where customers sign in and see their results.
• API: receives and processes customer data, including OAuth connections to other tools, a webhook for CRM events, and CSV upload.
• Nightly jobs: pull data from connected tools, including the Salesforce job described in section 6.

The platform processes campaign spend, lead counts, one-way hashed lead identifiers, and sale amounts and dates. Payment card details are handled by our payment processor, and we do not store full card numbers. The platform is designed to operate without consumer health information.

3. Data in Transit

Encryption is the starting point of CDAI security.

• All traffic to the client portal and the API uses HTTPS/TLS. In an independent SSL Labs test on October 6, 2026, the API received grade A and the portal received A+ and A.
• Connections between our API and our database are encrypted, and the database refuses connections that are not.

4. Data at Rest and Customer Isolation

Keeping each customer's data separate is a core part of CDAI security.

• Row-level security is enabled on every table in our database.
• The database functions that the client portal calls check that the signed-in user belongs to the organization requested. A user who does not belong to it receives no data.
• Customers cannot read, change or delete other customers' records, or read stored connection credentials, through the portal's database access.

5. Salesforce Connection

CDAI security for the Salesforce connection rests on a few simple rules. Customers decide when to connect, and they can end the connection at any time.

• Customers connect Salesforce with OAuth 2.0 and PKCE (RFC 7636). We never receive or store a Salesforce password.
• We request the Salesforce api and refresh_token permissions. Our integration only reads data by running queries. It does not create, change or delete anything in a customer's Salesforce org.
• Salesforce access and refresh tokens are encrypted at rest.
• When a Salesforce connection is disconnected, we revoke the token with Salesforce and delete the stored tokens from our database. A customer can also revoke our access at any time from Salesforce.
• We only send requests to Salesforce addresses. A connection that returns any other address is refused.

6. What We Read From Salesforce

A nightly job reads three kinds of records from each connected Salesforce org, using read-only queries. The job runs once a day at 02:00 UTC.

• Leads that have not been converted: the record ID, email address, creation date, lead source, and the campaign tracking fields (UTM campaign, source and medium) when the org has them.
• Contacts: the same fields as leads.
• Closed-won opportunities: the amount, close date, stage and lead source, plus the primary contact's email address, which is used to link a sale to the lead that produced it.

First and last names are part of the lead and contact queries but are never stored. The email address is converted to a one-way SHA-256 hash before anything is saved, so the platform keeps the hash, the creation date, the campaign the lead was matched to, and the amount and date of the sale. We do not store Salesforce contact names or phone numbers.

A record that cannot be matched to a campaign stays unattributed. It is never guessed. This keeps the revenue figures that customers see tied to real data.

7. Where Data Is Stored and Who Processes It

Where data lives is part of CDAI security. Customer data is stored in a Supabase database in the US West (Oregon) region. The API and the nightly jobs run on Render in its Oregon region. The providers below process data on our behalf. Beyond them, we share customer data only in the limited cases described in section 4 of our Privacy Policy.

• Supabase: database and sign-in.
• Render: API and nightly jobs.
• Vercel: client portal web files.
• Resend: email delivery.
• Stripe: subscription payments.
• Anthropic: receives a summary of system health, without lead-level records, to produce a daily brief for Allocera staff.

8. How We Build and Change CDAI

How we change the platform is part of CDAI security. Code changes are made on separate branches, covered by automated tests, and merged to production only with the owner's approval. Our tests include checks that deliberately broken code is caught, and security fixes are tested before they are deployed.

9. Monitoring

Daily monitoring is part of CDAI security.

• An automated health check runs against production every day.
• A daily monitoring report reviews connection health, token expiry, data volumes and data integrity, and flags anything unusual to Allocera staff.

10. What You Can Do

Customers play a part in CDAI security too. We recommend these steps.

• Connect Salesforce with a dedicated integration user that has only the access CDAI needs to read leads, contacts and opportunities.
• Review the Connected Apps OAuth Usage page in Salesforce from time to time, and remove access that is no longer needed.
• Use a unique password for the client portal, and tell us when a portal user leaves your team so we can remove their access.

11. Retention and Deletion

We retain data for the duration of the service agreement and up to 36 months afterward. On termination, portal access is suspended immediately, and data is returned or destroyed on written request within 30 days. See section 6 of our Privacy Policy.

12. Reporting a Security Concern

Email alloceraintelligence@gmail.com with the subject line "Security." We commit to prompt notification of customers in the event of a confirmed breach affecting their data. Questions about CDAI security are answered at the same address.