Security
Deft sits in the path between your people and their AI providers. That is a serious thing to ask of a company, so this page answers the questions a reviewer would ask before signing anything — including the ones with uncomfortable answers.
Last updated [DATE NOT YET SET]
Where Deft sits
Requests from the Deft app or from a configured client go to our gateway, which authenticates the caller, resolves which provider credential to use, and forwards the request to Anthropic, OpenAI, or Google. The provider’s response streams back to the user.
Classification runs outside that path. The response returns first; only then does a background worker classify what kind of work the request represented. Nothing about the analytics layer can delay or block a user’s request, and a failure in it cannot break a conversation.
Prompt and response content passes through the gateway in memory and is forwarded to the provider. It is not written to our database. The one exception is stated in full in the next section.
What is stored, and what is not
| Data | Stored | Retention |
|---|---|---|
| Prompt and response content via the gateway | No | — |
| 200-character preview, only when classifier confidence is below 0.65 | Yes | 14 days, then erased by a scheduled job |
| Classification metadata — category, confidence, model, token counts, timestamp | Yes | Life of the account |
| Conversations held inside the Deft app | Yes | Until deleted by the user |
| Provider API credentials | Yes, encrypted | Until removed by the customer |
| Email, document, or Slack message bodies | No | — |
The retention window is enforced by a daily job, not by policy alone, and its value is deployment configuration rather than something buried in code.
Tenant isolation
Every organisation-scoped table enforces row-level security in PostgreSQL. Isolation is applied by the database against the caller’s authenticated identity, not by filters in application code.
This distinction is the point: application-layer filtering fails open when a query is written wrongly, because the database will happily return whatever was asked for. Row-level security fails closed — a missing filter returns nothing rather than someone else’s data.
- Row-level security is enabled on organisation-scoped tables, including partitioned ones.
- Direct table privileges for anonymous and authenticated roles are revoked; access goes through policies.
- Service-role credentials are used only by server-side workers, never shipped to a browser.
Authentication and access
- Sessions are validated server-side against the identity provider’s signing keys on every protected request. We do not trust a session cookie’s contents without verifying its signature.
- Provider API credentials are encrypted at rest with Fernet (AES-128-CBC with HMAC-SHA256 authentication) under a key held in deployment configuration, not in the database.
- Traffic is TLS-encrypted in transit; data at rest is encrypted by our hosting providers.
- Organisation creation is gated in production. Accounts are provisioned by invite.
Today, the founder, for operating and supporting the service. We are a small company and will not pretend to a separation of duties we do not have. Access expands only alongside a written internal policy, and this page changes when it does.
Infrastructure and subprocessors
| Provider | Role |
|---|---|
| Supabase | PostgreSQL, authentication, storage |
| Railway | API and gateway compute |
| Vercel | Web application |
| Anthropic, OpenAI, Google | Model providers |
| Sentry | Error monitoring, configured without personally identifying request data |
Hosting regions and a current subprocessor list with contract details are available on request. Where a customer supplies their own provider key, that traffic is billed to and governed by their own provider account.
What we do not have yet
Stating this plainly is more useful to you than discovering it in week three of a procurement review.
- No SOC 2 report. Not started. If a deal depends on one, tell us and we will discuss timing honestly rather than promise a date.
- No third-party penetration test. Security work so far is internal review and hardening of database access controls.
- No BAA, and Deft is not suitable for protected health information.
- No formal sub-processor change notification period beyond updating this page and the Privacy page.
Reporting a vulnerability
Send it to [security@yourdomain]. We aim to acknowledge within two business days and to keep you updated until it is closed.
Good-faith research is welcome. Please do not access data belonging to anyone else, degrade the service for other users, or run automated scanning without contacting us first. We will not pursue legal action for research conducted along those lines.