Trust, Security, and SOC 2 Alignment

Not certified · control environment disclosed

Trust, Security, and SOC 2 Alignment

Last updated 16 September 2026 · Effective immediately · Experimental system

Primacy Vault is NOT SOC 2 Type I or Type II certified, is NOT ISO 27001 certified, is NOT HIPAA compliant as a covered entity or BA, is NOT FedRAMP authorized, and has NOT completed a public penetration-test report as of this date. Claiming otherwise is a violation of the Anti-Hallucination Policy and the Acceptable Use Policy. This page describes the control environment we operate now and the evidence we intend to present to an independent CPA when a production backend, production hosting, and an audit period exist.

1. Intended future audit scope

When an audit is commissioned, the system description will cover: identity and access (account + wallet-connect for money actions), SuperGrok invocation, Outreach OS (human last-click, mail to the human, outbox), palace/vault data handling, in-software royalty ledger, change management, and vendor management (xAI, host, mail).

Out of scope until CAs are live: on-chain escrow, custodial wallets, and any claim of insured USDC. An auditor cannot attest to contracts that are not deployed.

2. Common Criteria (CC) — security

CC1 Control environment: written Legal Set, AUP, anti-hallucination policy versioned in software, experimental disclaimer on every legal surface.

CC2 Communication: this Trust page, FAQ, in-product copy that Arc CAs are not live, mail templates that tell the human they — not Primacy — send company email.

CC3 Risk: identified risks include model hallucination, fake settlement, spam, key loss, vendor outage, self-attested jobs, open mail relay, unbounded ledgers. Mitigations: Auditor BLOCK, client scanners, challenge codes, job gates (data-fit / terms / invoice), wallet gate, no auto-send, no invented buyer emails, process-revenue bound to the job, mint disabled, SuperGrok and mail rate limits.

CC4 Monitoring: SuperGrok dispatch log, outreach campaign states, mail outbox status, token transaction log, revenue_settlements with reverse on dispute. Production SIEM/alerting is a backend requirement you will provide.

CC5 Control activities: human last-click on send/job complete; stake lock enforcement; USDC ledger split from $PMCY; amount taken from the job not the client; preview wallets cannot Complete; 48-hour dispute clawback; Resend only when a key exists and only to a validated operator inbox.

CC6 Logical access: account session, PBKDF2 passwords, money actions require a linked Arc address with personal_sign for injected connect. Operator bootstrap phrase required for first admin. Production SSO/MFA is a backend requirement.

CC7 System operations: best-effort error handling; no SLA. Incident response in production will be documented in a later runbook.

CC8 Change management: source-controlled app; experimental releases may ship continuously. A change ticket process will exist for the audited production environment.

CC9 Risk mitigation / vendors: xAI processes prompts; mail vendor if connected. DPAs and SCCs are backend requirements.

3. Availability, confidentiality, processing integrity, privacy

Availability (A): no uptime commitment. Multi-region hosting is a future production choice.

Confidentiality (C): palace data is user-scoped in the experimental store. Do not treat it as HSMs or customer-managed keys.

Processing integrity (PI): royalty math is unit-fixed in source (85/7/5/3 of USDC earned, cap 90%). Job Complete is the integrity event. Preview ≠ chain.

Privacy (P): Privacy Policy; no sale of personal information; SuperGrok is opt-in per click.

4. SMTP / mail control objectives (launch integration)

Objective: notify the HUMAN operator so they log in and activate jobs. Company mail is not the default transport.

Now: templates (letter_ready, job_activation, sent_receipt); outbox; dispatchMail via Resend if RESEND_API_KEY is present; otherwise queue with an honest error; deep link /outreach?campaign=id.

Backend you will provide: production MAIL_FROM on a domain you control, SPF/DKIM/DMARC, optional dedicated sending subdomain, abuse mailbox, bounce handling, and — only if you explicitly authorize it — a separate path to SMTP-deliver a human-approved letter TO a buyer. Inbound reply parsing is a later control and is off.

5. Evidence we can show today vs later

Today: policy text in the repo and product; Auditor verdicts stored on campaigns; challenge codes and side jobs (data-fit, terms, invoice, dispute); mail outbox records; token and USDC ledgers bound to job ids; wallet-link list with injected signature proof; anti-hallucination flags on drafts; security protocol 1.1.0.

Later (backend): access reviews, pentest, vendor DPAs, SOC 2 Type I then Type II after a sufficient period of operation. We will not put a certification badge on the site until a report exists.

These documents are not a substitute for independent legal, tax, or investment advice. Primacy Vault is experimental. User beware.