Security and trust
Built to hold a professional’s trust, and to be reviewed.
This page is written for the security review that precedes a seat. It describes how data moves, how it is protected, who receives it, and what happens when something goes wrong. It claims only what the platform does today.
Revised 2026-09-27 · Operated by Athirium OÜ (entity being confirmed by the owner)
1. Data flow
Five steps, in order. Data enters at the first and leaves only at the last, on approval.
- 01ReadingFor each professional we ask the five AI engines (Claude, OpenAI, Gemini, Perplexity and Google) what they answer about the name and the chosen terms. The prompts carry the name and the terms, nothing else about the person. The answers are stored against the seat.
- 02MeasuringThe answers are scored into Standing and its four parts. A read that did not complete is recorded as not measured, never as a zero.
- 03ProposingThe AI Reputation Manager drafts the moves and the content, in the professional's voice, from the record and the readings. Every automatic action is metered before it may run.
- 04ApprovingNothing is published, sent or changed on the record without an approval row written by the professional or the operator. There is no bulk approval anywhere in the product.
- 05PublishingApproved work goes out through the channels the professional connected and their official page. Every outbound action is written to a ledger before it is sent; one that did not happen stays visible as unsent.
2. Encryption, isolation and access
- 01Encryption in transitEvery connection to the site, the admin application, the database and each subprocessor is TLS. There is no plaintext path.
- 02Encryption at restThe database and its backups are encrypted at rest by the managed Postgres provider. Portraits and generated images are stored in the same provider's object storage, also encrypted at rest.
- 03Row-level securityEvery table that holds a client record carries row-level security policies, so a seat can read only its own professional. Operators are tiered and every tiered action is logged with its actor.
- 04Least-scope accessWe request the narrowest access the work needs. Channel connections are the professional's own grants and can be revoked by them at any time.
- 05No personal information in logsApplication logs carry identifiers, never names, addresses or content. Page-view beacons store a daily-rotating hash, never a raw IP address or user agent.
- 06Approvals before publishPublishing, sending and record changes are gated on an approval row. Irreversible controls are armed before they fire. This is a product law, verified in the code and its tests.
- 07Audit trailEvery gate, decision and result is recorded with its actor and timestamp, so there is one account of what was done and why.
3. Approvals before publish
The professional approves or adjusts, one decision at a time. Nothing reaches a channel, an outlet or the official record without an approval row, and the ledger is written before any send, so a send that did not happen is visible as unsent rather than silent. The same rule binds the operator and every automated agent.
4. Subprocessors
As of 2026-09-27. Each receives only what its purpose needs. Hosting regions and the data processing terms are provided with the proposal.
| Provider | Purpose |
|---|---|
| Vercel | Hosting of the site and the admin application, edge network, build and deploy. |
| Supabase | Managed Postgres, authentication and object storage for the record, readings and approvals. |
| Anthropic | Claude: read as one of the five engines; drafting in the professional's voice. |
| OpenAI | Read as one of the five engines; image generation for approved drafts. |
| Gemini and Google, read as engines; Google Fonts for type on the site. | |
| Perplexity | Read as one of the five engines. |
| SerpAPI and SearchAPI | Structured reads of Google results for the name and the terms. |
| Ahrefs | Search and citation data about the official page and the record. |
| SendGrid | Transactional email to professionals and operators, written to the ledger first. |
| LinkedIn, X, Facebook | Publishing approved work through the professional's own connected accounts. |
5. Incident contact
A suspected vulnerability or incident is reported through the contact form, which reaches the operator directly and is acknowledged in writing. The same channels are published in machine-readable form at /.well-known/security.txt. An incident that affects a client’s data is reported to that client in writing, with what happened, what was affected and what was done, as the privacy policy sets out.
6. Roadmap to SOC 2 Type I
- TodayThe controls above, verified in the code and its tests. No certification is held and none is claimed.
- NextWritten policies (access, incident response, vendor review, retention) published to buyers with the proposal; a penetration test by an outside firm.
- SOC 2 Type IAn attestation of the design of these controls at a point in time, with an auditor engaged once the policies above are in force. The date is set with the first design partner and reported here.
7. For the review file
The privacy policy, the terms of service and the corporate FAQ complete the file. Anything a review needs beyond them is answered in writing with the proposal.