Trust & security
Sattva is an agent-native operating platform for nonprofits and impact organizations. A single AI agent runs on web and Slack, answers from an organization's own connected knowledge, runs its workflows, and produces durable artifacts—briefs, reports, and more.
Security is structural, not bolted on: every customer runs on a dedicated, single-tenant instance with its own isolated database, data is encrypted in transit and at rest, and our AI processing runs on commercial APIs that do not train on customer data. This page describes how that works, who we share data with, and how we support institutional obligations such as FERPA.
Single-tenant by design
Each Sattva customer runs on a dedicated, isolated deployment with its own database. We do not operate a shared multi-tenant database—one organization's data is never stored alongside, or accessible from, another organization's instance. This isolation is structural, not just a permissions rule.
Within each instance, access to data is enforced by Postgres Row-Level Security and authenticated access controls. Administrative operations run through a service layer with audited access.
Per-customer deployment
A separate database and deployment per organization. No commingling, by construction.
Row-Level Security
Postgres RLS plus authenticated access controls govern data access within each instance.
Audited operations
Administrative actions and agent runs run through a service layer and are logged for auditability.
Active AES-256 at rest
All data stored in Supabase PostgreSQL with AES-256 disk-level encryption.
Active TLS in transit
Every connection—browser, Slack, API, database—encrypted with TLS 1.2+.
Active Passwordless auth
Secure magic-link authentication. No passwords to leak or phish.
Active Row-Level Security
Postgres RLS plus authenticated, audited access enforce data boundaries within each instance.
Active Authenticated APIs
Every API route requires authentication. No anonymous access to organization data.
Planned SSO / SAML & RBAC
Role-based access controls and single sign-on for organizations that require them.
How the agent handles your data
The agent processes an organization's knowledge and requests to answer questions, run workflows, and produce artifacts. Here is exactly how that data is handled.
No model training
- AI processing runs on Anthropic's and OpenAI's commercial APIs
- Under those terms, customer inputs and outputs are not used to train their models
- Your organization's data and outputs remain exclusively yours
Data minimization
- The agent sends only the data relevant to the task at hand
- Typically the user's request plus the specific knowledge snippets retrieved to answer it
- Not an organization's entire data set
Human-in-the-loop
- The agent surfaces actions and deliverables for user review
- Consequential workflows keep a person in control of what is sent, shared, or committed
- Every agent run is logged for auditability
We're transparent about every third-party service that touches your data. Only the data necessary for each function flows to that processor.
| Service | Function | Data sent | Notes for reviewers |
|---|---|---|---|
| Anthropic | Core AI agent (chat, structuring), web search | Task-relevant prompt content + retrieved knowledge snippets | Commercial API; inputs/outputs not used to train models |
| OpenAI | Text embeddings for knowledge-base vector search (text-embedding-3-small) |
Text chunks of an org's indexed knowledge documents | Commercial API; not used for training by default |
| Supabase | Database, authentication, vector store | All encrypted application data + embeddings | Postgres, AES-256 at rest, Row-Level Security |
| Nango | Integration / connector infrastructure (OAuth + sync) | Connection tokens; brokers data sync from customer-connected sources | Brokers the optional customer-connected sources described below |
| Slack | Conversational surface for the agent | Messages to and from the agent | OAuth-installed per workspace |
| Railway | Application hosting | Application traffic | Managed hosting platform |
Customer-connected sources. Through Nango, an organization can optionally connect its own systems—for example Google Drive, Gmail, or Monday.com—as knowledge or workflow sources. The organization chooses which connectors to enable, and only the data it explicitly authorizes flows to Sattva; these remain the organization's own systems. The available connector catalog is broad, so we confirm the specific set in scope for each deployment rather than list it here.
We maintain a current subprocessor list and will provide notice of material changes to customers under contract.
FERPA & student education records
The Family Educational Rights and Privacy Act (FERPA) governs how educational institutions handle education records. Sattva is built to support an institution's FERPA obligations under the arrangements below.
FERPA compliance is established by the agreement between Sattva and the institution and by our shared practices; the institution remains the party responsible for its records. There is no such thing as a “FERPA certified” or “FERPA compliant” product stamp—we do not claim one.
- Scoped for institutional operations. Sattva is designed for an organization's operational and knowledge work—advancement, grants, HR, internal knowledge—which in many deployments involves no student education records at all. We work with each institution to scope what data the platform may access, and to keep education records out of scope where they aren't needed.
- “School official” arrangement. Where an institution does designate Sattva to handle education records, we operate as a school official with a legitimate educational interest under FERPA: we act under the institution's direct control, use the records only for the contracted purpose, and do not redisclose them.
- No redisclosure to AI providers' training. Data processed by our AI subprocessors (Anthropic, OpenAI) runs through commercial APIs that do not train on customer data. This is what keeps AI processing consistent with the no-redisclosure requirement.
- Isolation. Each institution runs on a dedicated, single-tenant instance—records are never commingled with another customer's data.
- Deletion & return. On request or contract termination, we delete or return education records, including derived copies such as search embeddings and synced content.
- Documentation for procurement. We will sign a Data Protection Addendum with FERPA terms and complete a HECVAT (Higher Education Community Vendor Assessment Toolkit) on request.
We label every commitment honestly: Active (true in production today), Planned (committed, not yet true), or Available on request (we provide, sign, or complete it when a customer asks).
- Planned SOC 2 Type II—independent audit of security, availability, and confidentiality controls. We do not have it yet.
- Planned GDPR—full alignment with EU data protection; DPA with erasure rights available on request.
- On request FERPA Data Protection Addendum—signed with FERPA terms for institutional customers.
- On request HECVAT (Lite / Full)—completed for higher-education procurement reviews.
- On request Security questionnaire / penetration test—we respond to standard security reviews.
Your data, your control
- Data export—organizations can export their data on request.
- Deletion across all stores—on request or contract termination, we delete data across primary tables, embedding chunks, synced source copies, and logs.
- Access controls—Postgres Row-Level Security plus authenticated, audited access.
- Breach notification—in the event of a data breach affecting your data, we commit to notifying affected customers without undue delay.
Request documentation
We're happy to walk through our security practices and data flows with your team, and to provide our DPA, a completed HECVAT, or a security packet on request.
Book a conversation →or email team@sattva.capital to request more information