Security at Cernia

Cernia reads your advertising, analytics and attribution platforms under your own keys and writes changes to them only with your approval. This page says how that is kept safe.

• Access
• Credentials
• What is read and kept
• Changes to your platforms
• Audit
• Models
• Isolation
• Incidents and disclosure
• Questions

Access

People sign in by email link, Google or Microsoft; enterprise single sign-on (SAML) is available per customer on request. Each business is an organization with its own workspace. Roles are owner, approver, analyst and viewer, and the approver role is the only one that can say yes to a change on your platforms. Slack users act only after they are linked to a verified account, and approvals in Slack are accepted only from a linked approver.

Credentials

The connections page is the only place a credential enters Cernia. Where a platform offers it, access is granted through that platform's own sign-in to Cernia's registered app, so Cernia never sees a password. Where a platform only offers an API key, the key is entered once and encrypted. Read and write grants are separate, and write grants are not requested until you enable changes.

Credentials are encrypted at rest with a key Cernia controls, decrypted only inside the request that uses them, and never written to a log, a report, a message or a model prompt. Revoking access on the platform side ends Cernia's access at once; so does removing the connection in Cernia.

What is read and what is kept

Cernia reads each platform live, at the moment a question is asked or a procedure runs. There is no warehouse and no standing copy of your account data. What is kept is declared: your dashboard series at daily, weekly, monthly, quarterly and yearly grain, the figures in recurring reports, plans and their read-backs, and the audit log. Everything else is pulled, used and discarded.

Customer contact data is never read. Connectors request reporting fields, not customer records, and an output scrubber and personal-data scan run on every report, chart and message before it reaches a person.

Changes to your platforms

Every change follows one contract: plan, dry run, approve by ID, apply, read back, roll back. A plan names each field it will change with its current and intended value, carries a hash and an expiry, and is applied only after your approver says yes to that plan. Each field is re-read immediately before it is written and the apply stops if anything has drifted. A rollback plan exists before the first change is made and the read-back after it is kept with the plan.

Some changes are refused by design: nothing is ever deleted, and budgets, bids, bid strategies, targeting, audiences and listing groups on existing objects are not changed until you enable that class of change for your organization. New campaigns, ad groups and ads are created paused and switched on only by a second approved plan.

Audit

Every read of your data, every plan, approval, apply, rollback and every use of a credential is logged with who, what and when. Owners can read the log in the web app at any time and export it. The log is append-only.

Models

Answers and drafts are produced by a model you choose: on Cernia's account, or on your own Anthropic or OpenAI key running on your tokens. Platform rows are summarised by scripts before a model reads anything, and no number reaches a person until the procedure's verifier has passed. Providers are used under their API terms, which exclude your data from model training, and nothing you connect is used to train anything.

Isolation

Organizations are separated at the database by row-level policies, and cross-organization reads are tested to fail. Production changes to your platforms are limited to an allowlist of accounts you name. Access by Cernia staff is least-privilege and reviewed. Controls are run to a SOC 2 standard from the start; an external audit is planned once the first external customer signs, and the report will be available on request.

Incidents and disclosure

If an incident touches your data or your platforms, you hear from Cernia first, with what happened, what was affected, what was done and what you should do, and the account record is corrected. Security researchers who find a problem can write to security@cernia.ai; reports are acknowledged within two business days and good-faith research is never met with legal action.

Questions

Does Cernia copy my data into its own warehouse? No. Cernia reads each platform live at the moment a question is asked or a procedure runs, keeps only what is declared (dashboard series, report figures, plans, read-backs and the audit log), and discards the rest.

Can Cernia change my campaigns without my say? No. Every change is a plan with an ID, a hash and an expiry. It is applied only after a person with the approver role in your organization says yes to that plan, and a rollback plan exists before the first change is made.

Does Cernia delete anything on my platforms? No. Deletes are refused by design. New objects are created paused and enabled by a second approved plan.

Are my credentials visible to anyone? No. Credentials are granted through each platform's own sign-in where it offers one, encrypted at rest with a key Cernia controls, decrypted only inside the request that uses them, and never written to a log, a report or a message.

Is my data used to train models? No. Model providers are used under their API terms, which exclude your data from training, and nothing you connect is used to train anything.