Security & trust
AssemblyWright reads a CRM org you connect, writes deliverables about it, and — only on an instruction from one of your authorized users — changes it. This page describes how that is protected, and, just as deliberately, what we do not yet claim. It may only say what docs/security-posture.md says; when a control changes, this page changes in the same commit.
Running a security review? The questionnaire below answers the standard questions once so you can forward them once. The legal documents — Terms, Privacy Policy, DPA, Acceptable Use — are published as drafts for attorney review and say so at the top of each.
Last reviewed: 2026-09-19.
What we do
Every workspace is isolated at the data layer, in one place. Every tenant-owned table carries a workspace identifier and the filter is applied once, at the ORM, rather than in each feature: reads are rewritten to add the scope, writes are stamped with it, an attempt to write without a scope raises rather than writing an unattributed row, and a read without a scope returns nothing rather than everything. It is proven against a real database — another workspace's row is invisible by query, by count and by direct primary-key lookup — and the live posture is reported by an open endpoint (/api/public-config → "tenancy":"enforcing"), so it is checkable rather than asserted.
Your CRM credentials are encrypted as a whole and never shown back. Connection credentials — a Salesforce private key and client id, a Dynamics client secret, a HubSpot private-app token — are encrypted at rest as one blob, not field by field, and the API returns field names only, never values. Settings are namespaced per workspace and secrets never fall back to a shared value, so one workspace cannot inherit another's org. Volatile token caches are cleared on every connection switch, so a token minted against one org is never replayed against another.
Nothing writes to your org by itself. The models draft, review and propose. Every write to a connected org — a metadata deploy, a bulk data update, seeded test data — is a separate, role-gated action taken on an instruction from one of your authorized users, and the Acceptable Use Policy leads with the rule that you connect only an org you are authorized to change, sandbox first. A metadata deploy snapshots the pre-deploy state with a one-click undo; a bulk update captures the prior record values before writing; seeded test data carries a removal tracer. Where those rollback payloads live is your choice — our database, or a file in your own org with only a receipt and a checksum kept here — and a capture that cannot be stored under the chosen custody fails the job rather than proceeding without a backup. What rollback cannot undo — the downstream automation your own org ran on a change — the Terms say plainly.
Accounts, roles, and elevated actions. Identity is provided by Clerk (RS256 tokens verified against published keys, issuer and expiry checked) and gates every API route; the only open paths are the health check, the public configuration, the authentication-readiness probe and the client-error beacon. Per-workspace roles — viewer, operator, admin, owner — are enforced in one middleware, and every destructive, cost-bearing or org-touching route (about 52 of them) requires an elevated role.
Spend cannot run away. A per-Build dollar ceiling warns at 80% and pauses for approval rather than running on; a model-call budget per Build pauses and asks rather than cancelling; a durable per-workspace budget brake is computed from recorded usage, not counted in memory; per-IP rate limiting trusts only the proxy-appended hop; and there is a daily Build cap.
Privileged actions are recorded. An admin audit table records the actor, the trusted client IP, the action and the detail for settings changes, model credentials, CRM connect and disconnect, vault operations, snapshot restores and permanent deletes — and the detail logs field names, never values. Structured request logs and capped client crash reports sit alongside it.
How code reaches production. Every backend module carries a self-test that must pass before merge; the full suite runs in CI on every push. Deploys rebuild, smoke-test and automatically roll back and quarantine a bad commit. Database migrations are never auto-applied. Production dependencies are pinned in a lockfile generated from a clean environment, the image installs from that lockfile, and the pins are scanned against the public advisory database with the dated output kept, and the two Node dependency trees (the web build tooling and the iPhone app's build tooling) are audited the same way — zero open advisories at the last pass (2026-09-19).
Backups, rehearsed. Daily PostgreSQL dumps to cloud storage plus daily disk snapshots, with a written disaster-recovery rehearsal and measured restore steps. TLS with automatic certificates on every hostname, HSTS, and a standard security-header set.
Written policies. Access review, incident response, change management, data classification and retention, and vendor management — each describing what actually happens and stating its own gaps. Available on request.
Questionnaire answers
Where is customer data hosted? On Google Cloud in us-central1 (a single virtual machine running the application and PostgreSQL), with backups in Google Cloud Storage in the same region. All customer data is stored in the United States; no regional choice is offered.
Is data encrypted in transit and at rest? In transit, TLS on every hostname with HSTS. At rest, Google Cloud encrypts the disks and storage; on top of that, credential-shaped values are encrypted at the application layer under a deployment key. Stated limitation: that key lives in the deployment environment on the host — there is no managed key service and no automated rotation procedure.
How are customers isolated from each other? Row-level isolation enforced at the ORM in one place, proven and reported live (above). Isolation is logical, not physical.
How is authentication handled? Clerk. Self-serve sign-up on Clerk Organizations is built; whether it is switched on for your deployment is reported by the public configuration. There is no SAML and no SCIM. MFA policy is the identity provider's.
What does the AI see, and does it train on our data? The prompt for a stage — your Build request, the org context imported from your connected org, Knowledge Base material, prior deliverables — goes to the model that answers. Production runs on Google Vertex AI in us-central1 under Google Cloud's enterprise terms, which provide that customer inputs are not used to train Google's models. Google AI Studio's free tier, whose terms permit training, is development-only by written policy and never sees customer data. Outputs may be wrong; review gates and human checkpoints exist so a person decides.
Do the models act on our CRM? No. Every write is a separate, role-gated act on a human instruction (above).
Do you store our passwords or tokens for other services? The CRM credentials you give us, encrypted as described, and — only if you switch on the Content Desk and connect a social account — the posting token for that account, encrypted the same way, never returned by any interface, and used only to publish a post after a recorded approval. Nothing else. Disconnecting deletes them.
What are your backup and recovery arrangements? Daily dumps and daily disk snapshots (snapshots kept 7 days), a rehearsed restore with measured steps, and an auto-rollback deploy path that has been exercised. No uptime commitment is offered.
What is logged, and can we get the logs? The admin audit trail (actor, IP, action, field names) — rotated to the newest 2,000 records, so export it from the admin area if you need a longer archive. Request logs and crash reports are operational and bounded.
How long is data kept, and how does deletion work? Deliverables, Builds, Knowledge Base entries and imported org context stay until you delete them; deleted items go to a trash with a type-to-confirm permanent delete. Rollback payloads are destroyed after 30 days by default (configurable per workspace), leaving a receipt. Deliverable text can be held in your own org instead of ours, and a retention window and version cap can be set — all off unless you set them. Deleting one individual's data is a manual process on request, confirmed in writing; we say so rather than implying a self-service path that does not exist.
Does customer content execute on your servers? No. Deliverables are documents. The only thing that runs against your systems is a deploy or data operation you instructed, through your CRM vendor's own APIs, with a rollback snapshot taken first.
How do we report a vulnerability? security@assemblywright.ai, published at /.well-known/security.txt per RFC 9116. We do not run a paid bounty programme and will not pursue researchers who report in good faith.
Subprocessors (as of 2026-09-19)
| Subprocessor | Purpose | What it can see | Region |
|---|---|---|---|
| Google Cloud Platform | Hosts the application, the database and the backups | Everything stored in the service | us-central1, USA |
| Google Cloud Vertex AI | Production AI inference | Prompt and response content: Build inputs, org context, generated deliverables. Does not train on customer inputs. | us-central1, USA |
| Clerk | Authentication and identity, including organization invitation email | Email addresses, sign-in metadata, session tokens | USA |
| Resend — only where a deployment has notification email configured | Delivering the product's own notifications: a Build finished, a review gate is waiting, your input is needed | The recipient address, the notification's title and detail, and a link back to the Build | USA |
| Apple Push Notification service — only if you use the iPhone app and push is configured | Delivering the same notifications to a phone | The notification's title and detail (never deliverable content, never CRM data), the Build's route, and a device token | Apple's network |
| Stripe — from the date we begin taking payment; not yet active | Payment processing | Billing contact and payment details (card data goes to Stripe, never to us) | USA |
| Let's Encrypt | TLS certificates | Domain names only | — |
| Profusia AI (Evadaroo & Company, LLC) — only if you connect it | Publishing your deliverables into your own Profusia workspace | The deliverables you publish | Cloudflare's network |
Not subprocessors: your CRM vendor (Salesforce, Microsoft, HubSpot — your own vendor relationship; we act on it with credentials you supply); the social networks you connect through the Content Desk (LinkedIn, Bluesky, Mastodon, Dev.to, X — your own accounts, receiving only a post a person approved); Google AI Studio (development only, by written policy); GitHub (application source only; no customer data, no production secrets).
We give 30 days' notice of a new or replacement subprocessor, as set out in the DPA.
What we don't claim
A security page that lists only strengths tells you nothing, because every security page lists only strengths. Here is the other half.
- No SOC 2, ISO 27001 or HIPAA attestation. None in progress. Deliberate for a product at this stage: the controls above are built and real, and a formal attestation follows a business reason to hold it. If your procurement requires a report, say so — that is exactly the business reason.
- No third-party penetration test. We publish a security contact and welcome researcher reports; we have not commissioned an independent test and do not claim one.
- Isolation is logical, not physical. Customers share infrastructure, separated in software — the same model most multi-tenant SaaS uses.
- No dedicated security officer, and the written policies have not been exercised. One operator answers. There is no on-call rotation.
- No managed key service and no key-rotation procedure. The application encryption key lives in the deployment environment on the host.
- The audit trail is bounded by row count, not time (newest 2,000), and is not shipped off-box. Export it if you need a longer archive.
- Rate limiters are per-process — fine for one container, a real gap at scale-out.
- No external uptime monitoring is in place yet. The health check answers "the process is up" and knows nothing about sign-in; a separate authentication-readiness probe exists for that, and hooking an external monitor to it is decided and not yet done. Detection today depends on a person looking.
- No uptime SLA, and no public status page.
- Deleting one individual's data is a manual process.
- Org-held custody of backups and deliverables has not been proven against a live Salesforce org — it is covered by in-memory fakes. Choose it knowing that.
Reporting something
If you believe you have found a vulnerability, please tell us — we would much rather hear it from you. security@assemblywright.ai; details at /.well-known/security.txt. Privacy questions and rights requests: legal@evadaroo.com.
Questions a review needs answered that are not here? Ask — we will answer directly, and add the answer to this page.