Security you can check, not just believe

Every AI product says "your data is safe." Nobody says what that means.

So here is what it means at Unyo — as mechanisms, numbers and dates, not adjectives. Where something isn't done yet, that's on this page too. A trust page that only lists wins isn't a trust page.

All live figures below were verified against the production database on 16 July 2026.

The short version

1. No user can read another user's data

Row Level Security is Postgres enforcing ownership at the database engine, below the application. If a bug in our code asks for the wrong row, the database refuses — the check isn't in the code path that has the bug.

Live count, 16 July 2026: 109 public tables, 109 with RLS enabled, 291 policies, 0 missing.

Every user-scoped table carries the same four policies:

ALTER TABLE public.X ENABLE ROW LEVEL SECURITY;
CREATE POLICY "Users view own X"   ON public.X FOR SELECT USING (auth.uid() = user_id);
CREATE POLICY "Users insert own X" ON public.X FOR INSERT WITH CHECK (auth.uid() = user_id);
CREATE POLICY "Users update own X" ON public.X FOR UPDATE USING (auth.uid() = user_id);
CREATE POLICY "Users delete own X" ON public.X FOR DELETE USING (auth.uid() = user_id);

Cross-user reads are possible only with the service-role key, which exists exclusively inside Edge Function secrets and is never shipped to a browser.

2. Your tokens are unreadable, even to us

When you connect Gmail, Outlook, Shopify or Stripe, the provider hands us an access token. That token is your account. It is never written to disk in readable form.

• Every token is wrapped with AES-256 (pgcrypto PGP, cipher id 9 per RFC 4880) before it touches storage.
• Tokens are never read from or written to a column directly — only through SECURITY DEFINER database functions.
• The plaintext exists in memory for the duration of one outbound API call, then it's gone. Never on disk. Never in a log. Never in an error message. Never in a queue payload.

Live proof, 16 July 2026: we decoded every populated token column in production and read the cipher byte. 17 of 17 are AES-256. Zero plaintext tokens exist in the database.

The key itself

The master key is a stable 32-byte random value in a singleton table whose only RLS policy is FOR ALL USING (false) — deny, unconditionally, to everyone. It's readable only through one SECURITY DEFINER function whose EXECUTE is granted to service_role alone.

Live privilege query, 16 July 2026:

Zero IDOR surface

An IDOR is when a function trusts a user id you hand it. We swept production for every SECURITY DEFINER function that is executable by anon or authenticated and takes a caller-supplied user_id without an ownership check.

The query returns no rows.

3. An independent scan, and what it found

An external assessor (TAC Security) ran a CASA Tier 2-oriented DAST against Unyo on 6 May 2026.

Result: 0 Critical, 0 High, 0 Medium. Nine findings total — 5 Low and 4 Informational. All nine were treated: six fixed, two formally accepted with externally-verifiable evidence, one informational.

The fixes were not cosmetic. Closing the CORS finding meant migrating 129 browser-callable edge functions off a wildcard origin onto an explicit allowlist.

The two accepted findings came with proof rather than a shrug: for the proxy-disclosure item we empirically demonstrated that our host silently ignores the Server header override it was asking for; for the subresource-integrity item, the vendor's own documentation forbids SRI on the resources in question.

4. We ask for less than we could — here are the receipts

Scope minimisation is easy to claim and easy to check, because scopes appear on the consent screen you're about to approve.

Google: from 9 declared scopes down to 5.

The result: gmail.modify is now our only Restricted scope — which also halves our audit surface.

And the scopes we refuse elsewhere, on purpose:

• LinkedIn — no r_emailaddress. We already know your email from your Unyo account.
• Slack — no files:read.
• Trello — no account scope. It would allow impersonation.
• X — no dm.write, no follows.write, no like.write. We post; we don't act as you.
• Shopify — read-only by grant. All seven scopes are read_*. Not one write scope is requested. Unyo is structurally incapable of changing your store.
• Stripe — read-only by construction. Four tools exist: revenue summary, recent charges, balance, payouts. There is no charge, refund or payout code path anywhere in the codebase. (Stripe gates its read_only OAuth scope behind a support request, so the grant itself is broader than our implementation — we're telling you that rather than letting you assume otherwise.)

5. Your inbox belongs to exactly one agent

Unyo has ten agents. Only Maya can touch your email. Ashley can't. Blake can't. Steve can't.

That isn't a personality trait or a line in a prompt — it's a runtime access control. Each agent's toolbox is mounted per-agent and filtered through a denylist at execution time. If Ashley's model decided to try, the tool isn't in her hands to call.

The same boundary is why the team structure exists at all: an agent with your entire business is an agent with your entire blast radius.

Meet the ten agents →

6. No agent sends, publishes or deletes on its own

This is the promise most AI products quietly break. Ours is enforced in the database.

17 irreversible actions require your explicit approval — the gate reads requires_confirmation from configuration, not from a prompt the model could be talked out of:

• Email — send, schedule, delete
• Calendar — delete an event, delete an entire calendar
• Social — publish to Facebook, Instagram, LinkedIn or X, and multi-platform publish
• Workspace — post to Slack, archive a Notion page, delete a Trello card
• Memory — delete a Neural Core entry

Because the gate is config-driven, it can be tightened without shipping code.

And the deeper design choice: automations draft, they never send. Unattended sending doesn't exist in Unyo. It's rejected in two separate places in the code path. Your 7am routine can read your inbox, think about it, and leave you a draft. It cannot decide to reply to your investor.

How automations work →

7. The AI sandbox has no internet and no secrets

When Blake runs real Python on your data, it runs in an isolated microVM. Four properties, all enforced in code rather than policy:

1. allowInternetAccess: false — the microVM cannot make an outbound network call. Not to us, not to anyone.
2. envs: {} — an empty environment allowlist. No host secret can physically enter the sandbox, because nothing is passed in.
3. A 20-pattern secret denylist that fails closed — if anything resembling an API key, private key or session token appears in the code or the data, the run is refused rather than sanitised.
4. Killed in a finally block, never paused — a paused sandbox is a snapshot that persists on someone else's disk. That's a GDPR Article 17 liability, so we don't create one. The sandbox is destroyed whether the run succeeded, failed or crashed.

Every hard limit — code size, input size, runtime, total deadline — is validated before a sandbox is ever created, so a malformed run fails fast and is never billed to you.

The same posture governs website previews: the sandbox makes zero outbound calls, and it refuses to serve a file containing a server secret.

8. Deleting your account actually deletes your account

Settings → Account → Delete my account. Three steps: a warning, typing DELETE, and a confirmation screen. Then, in seconds:

1. Every OAuth grant we can revoke, we revoke — at Google, Meta, X, Slack and Shopify.
2. Every website you published goes offline first — each live <slug>.unyo.site is unpublished before the records are dropped, so nothing survives on the internet after the row that described it is gone.
3. Your files are wiped from nine storage buckets.
4. ~80 database tables are purged atomically in a single server-side transaction, in a deliberate topological order, by one SECURITY DEFINER function.
5. Your authentication record is deleted.
6. A defensive second purge runs 1.5 seconds later — because we caught a real race in testing where the browser could re-create default rows in the window between the purge and sign-out. It's idempotent and it closes the window permanently.

A failing provider can never block your erasure. All ten revocation calls are individually wrapped. If Meta is down, your deletion completes anyway. Your right to be forgotten does not depend on someone else's uptime.

The providers we can't revoke for you — and we tell you which

Microsoft, LinkedIn, Trello and Notion offer no revocation API. We can't finish the job at their end, so the final screen lists exactly which ones, with a direct link to each provider's dashboard. That screen has no close button and an auto-logout countdown, so you can't miss it.

9. Old data deletes itself

Retention is a scheduled job in production, confirmed active = true, running at 03:00 UTC daily:

The job has a fuse circuit at 100,000 rows per table: if a run would delete more than that, it stops and flags an operator instead of quietly mass-deleting. Deletes are batched and idempotent, and each run writes an audit record — which itself self-prunes after a year.

10. Your content is never training data

Your Gmail, Drive and Calendar data is never used to train any AI model — not by us, not by anyone downstream. Every model Unyo uses runs under a no-training guarantee, and it's an engineering gate, not an aspiration: using an inference tier whose terms permit training on prompts is classified in our own rulebook as a critical regression that blocks the change from shipping.

Our Privacy Policy reproduces Google's four Limited Use clauses word-for-word — Gmail data used only to provide the feature, never for advertising, never for any other purpose, never transferred except to deliver the feature, comply with the law, or in a merger with notice to you. Altering that text is one of the ten regressions our rulebook blocks at commit time.

The concrete downstream rules: no human review of your Gmail-derived content unless you open a support request about it. No export of it to analytics, marketing or BI. No enrichment of external profiles with it. No lead-gen use of it. Ever.

And what we don't collect at all: no precise location, no device fingerprints, no cross-site tracking, no analytics on your content, and no sale of personal data.

11. Compliance is enforced at commit time

Most companies check compliance at audit time. We check it at commit time.

Our engineering rulebook names ten specific regressions, any one of which blocks a change before it ships:

• Storing an OAuth token without encryption
• Requesting a scope broader than necessary
• Sending user data to a model without a training-disabled guarantee
• Logging a token, refresh token or API key — anywhere
• Displaying a token in an error, an HTTP response or a stream
• Removing ON DELETE CASCADE from a user-scoped foreign key (it would orphan rows and break erasure)
• Disabling RLS on any user-scoped table
• Adding an OAuth scope without a Privacy Policy update and re-verification
• Changing account deletion so it leaves orphans, skips revocation, or hides the provider disclosure
• Modifying Google's verbatim Limited Use clauses

Any code change touching OAuth, token storage, scopes, edge-function auth, RLS, deletion, data export, or legal-document content has to clear that gate first. It's versioned, it's in the repository, and it's why the previous ten sections are still true a month after they were written.

12. The rest of the posture, briefly

• In transit: TLS 1.2+ everywhere, with HSTS (max-age=31536000; includeSubDomains; preload).
• Framing: X-Frame-Options: DENY plus frame-ancestors 'none'. Unyo cannot be embedded.
• Browser: X-Content-Type-Options: nosniff, a restrictive Permissions-Policy (camera fully disabled), no-store caching, and an explicit connect-src allowlist.
• Fingerprinting: our host's Server and infrastructure headers are stripped from every response.
• CORS: an explicit origin allowlist across every browser-callable function. Account deletion has its own stricter, hardcoded allowlist as an extra barrier, because it's irreversible.
• OAuth flows: HMAC-signed state with a 10–15 minute expiry and timing-safe comparison. Microsoft adds PKCE plus an OIDC nonce validated against the live JWKS, defeating id_token replay.
• Meta calls: appsecret_proof (HMAC-SHA256 of the token with the app secret) on our Meta publishing, token-refresh and per-user analytics paths — a CASA requirement most integrations skip.
• Billing: credits are server-authoritative. Reserve/commit/refund are service-role-only with row-level locking and idempotent refunds; the payment webhook validates its signature with a timing-safe compare plus replay protection. Credits cannot be forged from a browser.
• Admin accounts: MFA on every single one — identity provider, database, source control, hosting, cloud.
• Credential rotation: a written policy with a cadence per secret class (6 months for AI keys, 12 for OAuth client secrets and the service-role key) and four immediate-rotation triggers, including a sub-4-hour SLA on a detected leak in source control.

13. What we do not claim

The most important section on this page.

• Unyo is not "Google-verified". Verification is in progress. Until it completes, you'll see Google's unverified-app notice on the consent screen. We'd rather you see it here first.
• Unyo is not CASA-certified. An independent DAST returned 0 Critical/High/Medium on 6 May 2026. That is a scan result, not a certificate. No assessor is signed yet.
• Unyo holds no SOC 2 and no ISO 27001. Some of our infrastructure providers do. That's theirs, not ours, and we won't borrow it.
• Unyo is not EU-hosted. The legal entity is French and the Data Controller is in Paris, but processing happens in France, the EU/EEA, the United States and Canada, under the EU-US Data Privacy Framework and/or Standard Contractual Clauses. Anyone marketing this stack as "sovereign" would be lying.
• There is no end-user MFA yet. MFA is enforced on every administrator account. It is not yet available on yours. It's on the roadmap and it isn't shipped.
• Data export is not self-serve yet. Deletion is fully in-app and instant. Portability (Article 20) is currently an email request to privacy@unyo.ai with a 30-day SLA. A self-service export is in progress.
• Breach notification is a documented 72-hour process, not automated detection. If we become aware of a breach, you and the CNIL hear from us within 72 hours. We don't have automated breach monitoring, so we won't imply we do.
• Knowledge files you upload to your Neural Core are stored in a bucket that is readable by anyone holding the URL. The URLs are unguessable and never published, but this is not the same as private, and we're not going to describe it as private. Your database records, chat attachments, email attachments and generated deliverables are in private, owner-only storage. Migrating the remaining buckets to signed URLs is a known, tracked item.
• Unyo is pre-launch. There is no large user base and no production incident history yet. That cuts both ways and you should price it in.

If you want any of these to move before you commit, say so — it changes what we build next.

Who is accountable

Access, rectification, erasure, restriction, portability, objection, withdrawal of consent — all of it goes to privacy@unyo.ai, and all of it gets answered within 30 days. Erasure you can do yourself, right now, in under ten seconds.

FAQ

Still have a question we didn't answer?

Security questions get answered by the person who wrote the code, not by a support macro. privacy@unyo.ai.

See how the agents are separated → · How your data becomes shared memory → · What each integration can and can't do →