Security, privacy and AI use

Secret encryption

• Integration credentials (WordPress, APIs and webhooks), two-factor authentication secrets and social network tokens are stored encrypted with AES-256-GCM.
• The encryption key lives outside the database, in the server configuration.
• Each encrypted value identifies the key that encrypted it, which allows rotating the key without taking the platform down.
• User passwords are stored as bcrypt hashes, never as plain text.

Signed publishing

• Publishing webhooks sent by CDE carry an HMAC-SHA256 signature.
• The signature covers the send time together with the request body, so the destination can reject a request replayed outside the validity window.

Access control

• Two-factor authentication with an authenticator app (TOTP).
• Per-workspace IP allowlist, in IPv4 CIDR blocks: access from outside the list is blocked.
• Five roles with distinct permissions: owner, admin, editor, analyst and viewer.
• Support access to a workspace requires a specific permission, is scoped to read or write, expires in one hour and every action is logged.

Audit trail

• Administrative actions in the workspace are logged with actor, date, IP and the state before and after the change.
• Actions by the platform operations team have their own log, separate from the workspace log.
• Every content state change records origin, destination, action, actor type (person, policy or automated process) and reason.

LGPD and privacy

• Every user can download, as JSON, the data the platform keeps about them: profile, workspace memberships, preferences, audit events and AI usage attributed to them.
• Every user can delete their own account. Deletion is refused while they are the sole owner of a workspace, so the workspace is never left without someone responsible.

AI use

• AI provider keys stay on the server and are never sent to the browser.
• In production, if a provider is not configured, the request fails: the platform does not return simulated text instead.
• All generated content goes through automated QA before publishing. What fails does not publish on its own: it goes to human review.
• A quote attributed to a professional is only used after approval. Professionals can block sites where they do not want to appear, and publishing respects each one's exposure policy.

Content and responsibility

• CDE blocks what your rules forbid: banned terms, missing required disclaimers, claims with no source and invalid markup.
• Editorial responsibility stays with the client and the professionals who sign — which is why nothing publishes without one of them.
• Who approved, when and on what grounds is recorded at every change of a content's state.
• An article published with an error can be fixed and republished: the previous version stays in the history.

Reporting a vulnerability

• Found a flaw? Write through the contact form describing what you observed and how to reproduce it.
• We reply within two business days with what we found and a fix timeline.
• Please do not disclose the flaw publicly before the fix; responsible reporters are credited if they wish.
• We do not run a paid bounty programme. We say so here to avoid setting a false expectation.

What this page does not claim

We do not list certifications, an uptime SLA or the data retention rules of AI providers, because those are not CDE controls we can demonstrate here. For those questions, talk to the team through the contact form.