Security

Built so your credentials never touch the AI, every consequential action waits for a person, and your data never trains a model.

Hiring Sanaf means giving it a key to the systems that hold your customers, your calendar and your books. This page says exactly how much of a key, who else can see what, and which standards are held by whom.

  • SOC 2 Type 2connection layer and hosting
  • GDPRDPA on request
  • CCPAno sale of personal data
  • AES-256at rest, per workspace
  • TLS 1.2+in transit, everywhere
Where it lives

Installed into Slack or Teams. Nothing of yours to host.

Sanaf joins your workspace as an app you add with one click, through the same OAuth review flow every Slack and Microsoft Teams app goes through. The scopes it asks for are listed on the install screen, and removing the app removes its access in the same moment.

  • One app, one employee, mentioned like a colleague
  • Scopes shown before you approve them
  • Remove the app and the access is gone
Compliance

Compliance, and who holds what

The same table you will find on bigger vendors’ security pages, with one extra column of honesty: for every standard, who actually holds it and where you can check.

SOC 2 Type 2: app connections and credentials
Through Composio
Every app Sanaf signs in to is connected through Composio, which is SOC 2 Type II certified and ISO 27001:2022 audited, stores every OAuth grant and key AES-256 encrypted, and decrypts them inside its own execution layer, never inside our process and never inside the model’s context. Read their security page.
SOC 2 Type 2: hosting and database
Through Vercel and Supabase
Sanaf runs on Vercel and its database on Supabase, both SOC 2 Type 2 audited platforms with their reports published through their own trust pages. Read their security page.
SOC 2: Sanaf itself
Planned
The layers underneath hold their audits; our own Type 1 engagement is on the roadmap and we will say here when it is underway, not before. Until then the honest description is: audited platforms, unaudited application.
GDPR
In place
A data processing agreement on request, deletion of your workspace on request, and the connection layer’s own terms published in its trust centre. Data is held in the United States; we do not offer a choice of region yet.
CCPA
In place
We do not sell or share personal data for advertising, and we honour access and deletion requests from anyone whose data a workspace holds. What Sanaf reads inside your apps stays in your apps.
Encryption in transit and at rest
In place
TLS 1.2 or later everywhere in transit. AES-256 at rest on the platforms we host on, and every credential, token and site login encrypted with AES-256-GCM on top of that, bound to the workspace it belongs to.
Workspace isolation
In place
One tenant per workspace, enforced in the database with row-level security: a query from one workspace cannot return another’s rows, and a permanent test proves it on every change we ship.
Human approval on consequential actions
In place
Per kind of action, you choose do it, ask me first, or never, with conditions like an amount or a new contact. Unattended work runs one level stricter than work you asked for in the moment.
Action logging
In place
Every turn is a replayable record: what Sanaf read, what it called, what it asked, what it sent, with timestamps, kept in your workspace.
HIPAA
Not yet
We do not sign business associate agreements and are not set up for protected health information, even though the connection layer can. Medical practices can still hire Sanaf for scheduling and admin that stays clear of clinical data.
ISO 27001
Not yet
Not held by us and not in progress. If your procurement process requires it of the application vendor, we are the wrong vendor today and we would rather tell you now than at contract stage.

Where a row says the standard is held through a platform, that is exactly what it means: the audit belongs to the layer named, not to us, and the link is there so you can read it yourself. Where a row says not yet, that is the whole story: no asterisk and no certification implied by adjacency.

Data handling

What Sanaf does, and what it never does

Commitments are only worth reading if they are specific enough to be broken. These are.

What Sanaf does

Encrypts everything

TLS 1.2 or later in transit. AES-256 at rest, and every credential encrypted again with AES-256-GCM and bound to the workspace it belongs to, so a key from one workspace cannot be read in another.

Signs in with your permission, one app at a time

Nothing is connected until you approve it, and each connection is scoped to the narrowest permission that lets the work happen. The support job gets the inbox, not the books.

Waits for a person on anything consequential

Money moving, a contract going out, a customer being told something unusual: Sanaf prepares the work and stops. You set the rule per kind of action, and unattended work runs one level stricter.

Writes everything down

Every turn is a replayable record with timestamps: what it read, what it called, what it asked, what it sent. "What did Sanaf do on Tuesday?" has an exact answer.

Lets you revoke anything in one click

Every app connection, every site login and the Slack or Teams install itself can be switched off on its own, without touching the rest, from your console.

What Sanaf never does

Train models on your data

Your conversations, customer records and documents are not used to train any model, ours or a provider’s. The model providers we use do not train on data sent through their business interfaces, and we do not opt in to anything that would change that.

Read your secrets

Credentials live in an encrypted vault and are injected at the moment a call is made. The model sees the result of the call, never the key that made it, and no key is ever pasted into a chat, a prompt or a work log.

Act on its own where you said not to

The approval rules are the boundary. Anything marked ask waits for you, anything marked never is refused, and both decisions are written down with the reason.

Share across workspaces

One tenant per workspace, enforced in the database. Nothing Sanaf learns at one business is available to a Sanaf working at another, and a test proves it on every change we ship.

Pretend to be a person

Sanaf is labelled as AI wherever it speaks. If a customer asks whether they are talking to a person, it tells them the truth and offers to bring one in.

Keep your data after you leave

Delete your workspace and we revoke every connection and delete what we hold, and we confirm when it is done. Records we are required to keep for tax or legal reasons are the only exception.

AI safety

Four things that keep an AI employee safe to hire

An employee that reads untrusted text and can act on it introduces problems ordinary software does not have. These are the four controls that answer them.

Credentials stay in the gateway

Sanaf reaches your apps through a connection layer that holds the OAuth grants and keys. The model asks for an action; the gateway signs the request. The secret never enters the prompt, the chat or the log.

A person approves before it sends

Consequential actions stop at a card in your Slack, Teams or console with a one-line reason. You approve, decline or hold, and the decision is recorded.

No training on your data

Nothing you or your customers write is used to train a model, ours or a provider’s. Memory is per workspace, inspectable, and removed when you ask.

Workspaces are isolated in the database

Row-level security ties every row to one workspace. Sanaf’s own runtime has no way to query across it, and a permanent isolation test runs on every change.

Approval

Consequential actions stop at a card, and wait for you

This is what a held action looks like in your channel. Sanaf says what it wants to do and why, and nothing happens until a person answers.

An illustration of how the conversation reads, not a transcript from a client account.

The awkward part

Where a general AI tool stops, and Sanaf keeps going

The chat box you have tried takes your prompt at face value. Sanaf reads emails, documents and web pages that someone else wrote, so it has to treat them differently.

Prompt injection is treated as content, not orders

Someone can put instructions inside an email, a form or a web page and hope your AI employee follows them. Everything a tool returns is information to read, never orders to obey, and the actions worth hijacking are the same ones held behind your approval.

It can be wrong, and says so

A model can produce a fluent answer that is simply incorrect. Sanaf is told to say it does not know instead of guessing, never invents a reason for what it cannot do, and never makes up a price, a policy or a promise on your behalf.

Memory with receipts

Ask why it thinks something and it answers with when it learned the fact, where, and what it replaced. Correct a fact and the old one keeps its history. Nothing it acts on is untraceable, and all of it is yours to delete.

Named model providers, through one gateway

Every model call goes through one gateway to providers named on this page, under their business terms. You can see which model each turn used and change it per workspace.

Credentials and secrets

3,000+ apps. Zero secrets in chat.

Where an app supports it, Sanaf signs in with OAuth and never sees a password. Where a key is the only way, it is encrypted with AES-256-GCM, bound to your workspace, read only at the moment a call runs, and rotatable on request. Every connection is granted for one job and revocable one at a time.

OAuth first

A sign-in you approve, with the scopes shown, revocable from the app itself as well as from us.

Encrypted vault

Keys and site logins encrypted at rest and injected at call time, never stored in a message or a log.

Revoke one at a time

Switch a single connection off without touching the rest, and see which job each one serves.

Third parties

Who else touches your data

Running an AI employee means other companies are involved. These are the ones that can see any part of your data, and what each of them is for.

Composio
The connection layer: OAuth grants, keys and the calls Sanaf makes into your apps
The credentials for the apps you connect, and the requests and responses of each call
Vercel
Hosting for the console, the runtime, the file store and the sandbox Sanaf works in
Everything in your workspace, encrypted at rest
Supabase
The database and sign-in for the console
Your workspace: conversations, memory, approvals, the work log
Anthropic
One of the model providers behind reasoning and drafting
The conversation and the business context needed to answer it
OpenAI
One of the model providers, plus speech and transcription
The conversation and the business context needed to answer it
Google
One of the model providers, plus image generation
The conversation and the business context needed to answer it
Resend
Sending sign-in codes and notification email
Recipient addresses and the contents of those emails
Stripe
Billing and invoices
Your card details, which we never see, and your invoices
Cal.com
Booking a demo of the fully managed hire
Names, contact details and appointment times

This list is kept current as the product changes. If we bring in a new party that can see your data, we will tell you before it happens, not after.

Found a problem? Tell us.

We would rather hear about a vulnerability from you than read about it somewhere else. Email us with enough detail to reproduce it and we will confirm receipt within one business day and tell you what we are doing about it. We will not take legal action against anyone who reports a problem in good faith, who avoids touching real customer data, and who gives us a reasonable window to fix it before going public. We have no paid bounty programme yet, and we will say so rather than imply one.

Report a security issue
Questions we get

Straight answers about your data

Does Sanaf see my API keys and passwords?
No. Sign-ins happen through OAuth wherever the app supports it, so there is no password to see. Where a key is the only way, it is encrypted at rest, injected at the moment a call is made, and never written into a prompt, a chat or the work log. The model asks for an action; the connection layer signs the request.
Do you train AI models on our data?
No. Your conversations, records and documents are not used to train any model, ours or a provider’s, and we do not opt in to provider settings that would change that. The model providers we use do not train on data sent through their business interfaces.
What has to be approved before Sanaf acts?
Anything you mark as ask, per kind of action: sending money, sending a contract, emailing a new contact, and so on. Sanaf stops at a card with a one-line reason; you approve, decline or hold. Work it does on a schedule, with nobody watching, runs one level stricter than work you asked for in the moment.
Can one workspace ever see another’s data?
No. Every row in the database belongs to one workspace and row-level security refuses queries across them. Sanaf’s runtime has no path around it, and a permanent isolation test walks every table on every change we ship.
Which channels and messages can it read?
Only what you add it to. In Slack and Teams it reads the channels it is invited to and the threads it is mentioned in, with the scopes shown at install. It does not read a channel it is not in, and removing the app removes the access.
Which AI models does it use, and can I choose?
Models from Anthropic, OpenAI and Google, through one gateway under their business terms. Each turn records which model it used, and you can change the model per workspace from the console.
What about prompt injection?
Everything a tool returns, an email, a document, a web page, is treated as information to read, never as orders to obey, and the system prompt says so. The actions someone would want to hijack are the ones already held behind your approval, which is the reason the approval gate exists.
Can you send me your compliance documents?
Yes. Ask and we will send our data processing agreement, the subprocessor list on this page, and the links to the SOC 2 reports and trust pages of the platforms Sanaf runs on. We will also tell you plainly which standards we hold ourselves and which we do not.
Do you support SSO?
Sign in with Google or with a code sent to your email today. SAML single sign-on for larger teams is on the roadmap; if it is a requirement, tell us before you commit to anything.
Where is our data hosted?
In the United States, on the platforms listed in the subprocessor section. We do not offer a choice of region yet, so if your obligations require data to stay in a specific jurisdiction, raise it with us first.
How do we delete our data?
Delete the workspace from the console, or ask us. We revoke every connection, delete what we hold and confirm when it is done. Because the work happens inside your own accounts, most of your data was never ours to hold: you keep it by keeping the account.
What happens if Sanaf does something wrong?
You tell us, we fix it, and we tell you what caused it. The work log usually shows exactly what happened rather than a reconstruction. Anything consequential sits behind your approval precisely so a mistake is caught before it reaches a customer.

Something here not covered? Ask us before you commit to anything.

Start free. Pay only when you are ready.

Hire Sanaf with $120 of free credit and no card, and watch every rule on this page hold on your own work before you decide anything.