Publishing CRM data should feel risky. Here is what we do about it.

A new view publishes nothing. Not a sensible default set, not the first five columns. Zero. You switch on each attribute you want a viewer to see, one at a time, and rename it if the internal label is not the one you would use with a client.

Then, at publish, we render the page. Not a summary of your settings and not a mock: the same renderer your viewer gets, with your real records and only the attributes you chose. You check it against reality rather than against a configuration screen, which is a different question from the one a settings screen answers.

The same screen argues with you in four specific places, on purpose:

• It flags the attributes worth a second look rather than counting them: currency, references to people, email addresses, phone numbers, personal names, and any label that reads like salary, cost, margin, internal, or private.
• A source that matches zero records, and a source with no filter at all, each need an explicit confirmation before they publish.
• The filter builder says out loud that is not also matches records where the field is empty. A filter reading “stage is not Lost” publishes every record with no stage set, which is rarely what the person writing it pictured.
• Publishing a page with no password, no email gate and no expiry asks you to confirm that, in those words, because a link that works for anyone who receives it also works for anyone they forward it to.

After it is published, two things keep watching. A view whose membership jumps by half again, and by at least 25 records, pauses itself and asks you. And a weekly digest tells you what of yours is currently public, because the dangerous view is the one published in March and forgotten.

Every view is read-only until you mark specific attributes editable. That permission is per attribute, off by default, and enforced on our server. The flag in the browser is advisory. The server check is the feature, and a viewer with dev tools open gets the same answer as a viewer without them.

When a viewer does change an editable attribute, it does not reach Attio. It becomes a pending edit in your dashboard. You see the proposed value beside the value Attio holds right now, read at the moment you look, and it is written only when you approve it. There is no setting that skips this and no plan that turns it off.

Underneath that, five things happen to every submitted edit:

• The target row is resolved through the viewer’s own accessor before anything else. A row key belonging to a record outside that view returns a 404 byte-identical to the one for a record that does not exist.
• The value is validated against the attribute type before it queues, and validated rather than coerced. A viewer cannot stage something the field would reject.
• At approval we re-read that single attribute from Attio. If it moved since the viewer proposed the change, we do not write over it. We show you both values and let you decide.
• Only simple attributes can be made editable in this version: text, number, date, checkbox, and single-select and status, where Attio reports the attribute as writable and it is not multi-select. Multi-select, linked records, locations, currency and ratings are read-only, because getting one of those writes wrong changes more than the record you were looking at.
• Write endpoints are rate-limited per session, per view and per tenant, and every edit lands in the audit log with a timestamp and, on a gated view, the viewer’s verified email address.

Published pages are never stored in a shared cache. No incremental static regeneration, no CDN copy of the HTML, no shared max-age. The rows are cached on our own infrastructure and invalidated in one step; the page itself is assembled per request.

That costs us a little speed and buys the one property this product cannot do without. “Pause takes effect immediately” and “an edge node somewhere may keep serving the old page for a while” cannot both be true, and for a product whose whole pitch is controlled exposure, a page that keeps serving after you hit pause is the worst failure available.

Three ways off, and each one is a defined procedure rather than a delete statement:

• Pause or unpublish a view. No request that begins after the transaction commits sees data: the status is read before any row is, and the same transaction revokes every existing viewer session. The cached rows are not deleted and do not need to be, because nothing can reach them while the view is down. Your configuration is kept, so you can publish it again.
• Disconnect a workspace. Every cached record from it is deleted, the stored token is overwritten, and the views built on it are paused rather than removed, so reconnecting does not mean rebuilding. We do not delete your work to punish a disconnect.
• Delete the account. Every view is paused and audited, every connection is disconnected, and the deletion cascades through every table that carries your tenant id. A check afterwards queries for any row anywhere still carrying it. Erasure has to complete without anyone here intervening, because you are the controller and we are the processor.

Attio access tokens are encrypted at rest with AES-256-GCM under a key id, so keys can be rotated without re-consenting every workspace. Attio’s tokens do not expire, which makes a stored one worth more than the usual secret and rotation worth more than the usual effort.

Our logger serializes through an allowlist of key names, so a key nobody thought of is dropped rather than printed. A denylist would fail open on exactly the field nobody anticipated. Passing record values to a log call is a build failure, not a guideline. Viewer IP addresses are stored hashed.

Two tables hold a viewer’s email address and they are the only two permitted to: the verified viewer session, purged aggressively, and the per-viewer access log on Business, kept for that plan’s analytics retention. Both are scoped to your workspace, both are deleted when the view or the account is, and neither value ever reaches a log line or an analytics rollup.

The subprocessor list names every vendor that can reach any of this, and the draft DPA sets out the processor terms. Both are drafts awaiting legal review and say so at the top.

A security page that only lists strengths is an advertisement. The other half, current as of 20 August 2026.

• No SOC 2, no ISO 27001, no third-party penetration test. We hold no security certification of any kind and are not going to imply one with a badge or with a phrase standing in for one. When we complete an audit, the report will be named here with its date and its auditor.
• Per-viewer row scoping is not available yet. It is in the launch build and it is not shipped. Until it is, everyone who can open a view sees every record in that view, and any use that depends on one person not seeing another person’s row should wait for it.
• Single sign-on for your own team is not built. It is priced on Enterprise and there is no screen behind it today.
• Everything runs in the United States. The database is in AWS us-east-2. EU data residency is not available.
• No uptime number. Nothing has been measured, so there is nothing honest to publish. The status page says what it will report once there is something to report.
• No bug bounty. There is an inbox and a person who answers it.
• No customer has run a security review of this product yet, because there are no customers yet. If yours is the first, we would rather take the questions than dodge them.