Skip to content
New

DeepSeek V4.1 Flash free for 7 days: 10M tokens a day after any top-up. Until Nov 30.

How it works
Create account

The controls we run, and the ones we have not built.

What a request passes through, how tenants are kept apart, which keys protect what, and what we have not certified. This page describes what runs in production today.

[email protected]What we have not done
/.well-known/security.txt
Contact
mailto:[email protected]
Expires
2027-11-01T00:00:00.000Z
Preferred-Languages
en, pt, es
Canonical
https://notholy.com/.well-known/security.txt
Policy
https://notholy.com/en/security

One API request, hop by hop

Each party that handles a request and what it can read. The outlined part is the one we operate.

  1. Your client

    Can read

    Your prompt and your API key, sent over TLS.

    Keeps

    Whatever your own tooling saves.

  2. Cloudflare edge

    Can read

    The whole request, decrypted in transit, and your IP address. TLS ends here for every hostname, including api.notholy.com, and a new TLS connection carries the request to our origin.

    Keeps

    Set by Cloudflare's own terms.

  3. NotHoly gateway

    Can read

    The request, in memory. It checks the HMAC of your key, its budget and its allowlists, then routes the call.

    Keeps

    Usage metadata: request id, organization, key, model, tokens, cost, status and timings. That record has no prompt, output or IP address. The response to a non-streaming call with an Idempotency-Key stays in memory for 24 hours.

  4. AI data center partner

    Can read

    Messages, tools and model parameters, over HTTPS and under our key. Your organization, user id and IP address are not forwarded. The partner is in the United States or China and may use its own subcontractors.

    Keeps

    Nothing. The partner has confirmed to NotHoly that it does not retain, store or use inference content, and NotHoly checks it periodically.

Tenant isolation

Organizations are separated in the application: every query path filters by org_id.

Keys
Each organization has its own encryption key, so one tenant's key cannot open another tenant's sealed data.
Ledger
Balance changes are insert-only, enforced by a database trigger. Payment webhooks must carry a valid signature.

Identity and access

Customer sign-in, API keys and staff access each have their own controls.

Passwords
12 to 256 characters, and a verified email address is required.
Second factors
TOTP with backup codes, and passkeys.
New devices
A password sign-in from an untrusted device needs a one-time email code. The code is stored as a keyed hash, lasts 10 minutes, works once and allows 5 attempts.
Trusted devices
Remembered for 30 days, stored hashed, and revocable.
Sessions
14 days in an HttpOnly, Secure, SameSite=Lax cookie. You can list your sessions and revoke them.
Bot checks
Cloudflare Turnstile on sign-in, sign-up and password reset, verified on the server. In production it fails closed.
API keys
Stored as HMAC-SHA-256 with a server-side pepper and shown once. A key can carry IP and model allowlists, a budget and an expiry date. Revocation is immediate.

Staff access

Admin sign-in
Passkey only. Sessions last 8 hours and end after 30 minutes idle, and an IP allowlist is available.
Admin changes
Logged with the actor, the action, the target and the values before and after.
Ledger adjustments
Anything over US$100 needs a second approver.
Impersonation
Staff have no feature for acting as a customer.

Encryption

Chats, projects and files are encrypted on the server, with keys we hold. We decrypt them to run your chat, so this is server-side encryption and it is not end-to-end.

Key hierarchy for chats and files

  1. Master key

    Held in the server environment. Wraps every organization key.

  2. Organization key

    One per organization. Wraps that organization's data keys.

  3. Data key

    One per conversation and one per file.

  4. Sealed content

    AES-256-GCM with a 12-byte nonce. Covers chat titles, messages, reasoning, projects, file names, file bytes and extracted text.

In transit
TLS from your browser to Cloudflare, with HSTS for 2 years and preload, then TLS from Cloudflare to our origin. The gateway reaches AI data center partners in the United States and China over HTTPS. Services inside our private network talk in plaintext.
Passwords
Account, chat lock and share passwords are hashed with scrypt. Share tokens are stored as SHA-256.
Ephemeral chats
Run events use a random 32-byte key per run, held only in process memory.
Not encrypted per column
Name, email, phone, billing address, tax ID, IP address and usage metadata are ordinary database columns.

What happens to your content

API inference content is not written to a database, queue, log or trace. Saved chats are stored encrypted until you delete them.

API inference

Content we store
None. Prompts and outputs exist in gateway memory while the request runs.
Protection
TLS in transit.
Removed
When the request ends, apart from the idempotency cache described below.
What stays
Usage metadata.

Saved chat

Content we store
Titles, messages, reasoning, citations and attached files.
Protection
AES-256-GCM, with one key per conversation and one per file.
Removed
When you delete the conversation. Attached files are not removed with it.
What stays
A tombstone for the conversation, run records, tool-step labels, attached files and usage metadata.

Ephemeral chat

Content we store
No conversation and no messages. Encrypted run events, plus any file you upload.
Protection
Run events use a random key per run, held only in process memory. Uploaded files use a per-file key wrapped by the organization key.
Removed
Run events are deleted 1 hour after the run ends.
What stays
A run record, tool-step labels, any uploaded file and usage metadata.
Idempotency cache
If you send an Idempotency-Key on a non-streaming call, the full response stays in gateway process memory for 24 hours so a retry gets the same answer. It is never written to disk, only your organization can replay it, and a restart clears it.
Tool-step labels
Chat runs record each tool call's target in cleartext, with no automatic expiry: the web search query, file search query, CVE query, file name or read_url hostname. Citation URLs are cleartext too.
Model training
We do not use customer content to train AI models or for model analysis. Metadata is analyzed for billing, abuse monitoring and operations.
AI data center partners
Every partner is in the United States or China and has confirmed to NotHoly that it does not retain, store or use inference content. NotHoly verifies and checks them periodically.

File handling

Sandbox not active in production

Uploads are treated as hostile and no user file is ever executed. Parsing is built for a disposable sandbox that production does not run yet. This covers chat uploads, /v1/files and the MCP analyze_file tool.

At rest
File names, bytes and extracted text are sealed with a per-file key before they are stored. Analysis writes the decrypted file to a temporary directory and removes it when the step ends. The file record keeps only the hash, size and MIME type in cleartext, and a file name can appear in a tool-step label.
Sandbox design
Each analysis gets a fresh container with no network, a read-only root, memory, CPU and process limits, all capabilities dropped, an unprivileged user and no secrets.
In production today
The production harness has no sandbox runner, and nothing else parses uploads. A file stays sealed in storage, is marked rejected and is not analyzed until the sandbox is switched on.

Network and SSRF

The origin accepts only Cloudflare on its public ports. The one server feature that fetches URLs runs behind an SSRF guard.

Origin
Ports 80 and 443 accept connections only from Cloudflare address ranges. Internal services listen on loopback.
Server access
SSH by key only, with fail2ban.
read_url
Public http and https on ports 80 and 443. Every resolved address is checked, the connection is pinned to the checked IP and each redirect is checked again. No cookies are sent, size and time are capped, and robots.txt is respected.
Traffic to third parties
Our servers do not scan, exploit or send active traffic to third-party systems. read_url only reads public pages. CLI commands run on your machine, after you approve them.

Application hardening

These are the response headers notholy.com sends today. Browser source maps are not served publicly.

curl -sI https://notholy.com/en
Strict-Transport-Security
max-age=63072000includeSubDomainspreload
Content-Security-Policy
default-src 'self'script-src 'self' 'unsafe-inline' https://static.cloudflareinsights.com https://challenges.cloudflare.comstyle-src 'self' 'unsafe-inline'img-src 'self' data: blob: https:font-src 'self' data:connect-src 'self' https://api.notholy.com https://cloudflareinsights.commedia-src 'self' blob:worker-src 'self' blob:manifest-src 'self'frame-src https://challenges.cloudflare.comframe-ancestors 'none'object-src 'none'base-uri 'self'form-action 'self'upgrade-insecure-requests
X-Frame-Options
DENY
X-Content-Type-Options
nosniff
Referrer-Policy
strict-origin-when-cross-origin
Permissions-Policy
camera=(), microphone=(), geolocation=(), payment=(), usb=(), interest-cohort=()
Cross-Origin-Opener-Policy
same-origin

The highlighted directive is the weak spot: our CSP is not nonce-based, and script-src still allows 'unsafe-inline'.

Monitoring and audit trail

Metrics and dashboards stay on our own host, and no third-party error tracker is active.

Metrics
Prometheus and Grafana on our own host, bound to loopback. Metrics carry labels and counts only and are kept 30 days.
Application logs
Request ids, status and errors, never request bodies. Rotated by size, at 3 files of 10 MB per container.
Staff audit trail
Actor, action, target, values before and after, IP address and user agent.
Organization audit log
Company organizations can review the latest 100 entries in Settings, if their role allows it.

Backups and recovery

The database is backed up once a day, encrypted and stored off-site.

Encryption
AES-256, with the key derived by PBKDF2 at 200,000 iterations.
Retention
14 daily, 8 weekly and 12 monthly copies. Data you delete can remain in a backup for about 12 months.
Restore drill
A scripted drill restores the newest backup into a throwaway database, verifies its checksum and checks that every table is present with no more rows than the live one. It does not run on a schedule yet.
Data loss window
A failure between backups can lose up to one day of writes.

Report a vulnerability

We expect researchers to test us. Here is how to report what you find.

Where
[email protected]. Our security.txt is at /.well-known/security.txt.
Include
The affected URL or component, steps to reproduce, and the impact you observed.
Scope
notholy.com, api.notholy.com and docs.notholy.com. Do not test other customers' data, do not run denial-of-service tests, and stop once you have shown impact.
Our side
We confirm we received your report, keep you updated while we fix it, and will not pursue good-faith research that follows these rules.
Rewards
We do not run a paid bounty program.

What we have not done yet

If your review depends on one of these, ask us before you rely on NotHoly.

[email protected]

  • Certifications

    NotHoly holds no SOC 2, ISO 27001 or other security certification or attestation.

  • Independent pentest

    We have no third-party penetration test report to share.

  • End-to-end encryption

    The server holds the keys and decrypts chats and files to process them.

  • Database-enforced isolation

    Tenant isolation lives in application queries. The database adds no second layer today.

  • File sandbox in production

    The sandbox is built and does not run in production, so uploads are stored and not analyzed.

  • Automatic deletion

    Uploads carry an expiry date and company organizations can pick a chat retention period, but no job enforces either one today. Usage metadata and audit records have no deletion job, so they are kept with no end date. Expired session records, which hold an IP address and user agent, are not purged on a schedule.

  • Organization-wide 2FA

    Owners cannot yet require a second factor for every member.

  • Log export and immutability

    The organization audit log cannot be exported, and our logs are not write-once.

  • Point-in-time recovery

    Backups are daily dumps with no continuous archiving, and they do not include uploaded file objects.

Ask anything your scope allows.

Create an account, add credits from $10 and ask the first question in the chat or the terminal.

Create accountSee pricing
  1. 1/3

    Create the account

    Individual or company. You can switch to a company later without losing balance or keys.

    IndividualCompany
  2. 2/3

    Add credits

    By card, from $10. Pay per token, no subscription.

    $10.00minimum deposit
  3. 3/3

    Ask

    In the chat, or install the CLI and run notholy login in your terminal.

    $ notholy login