Security

This page is about Sentisec's own security posture — how the platform holds your credentials, what it stores, how long it keeps it, and how you verify the evidence it produces. It is written for a reviewer who has to sign off on putting Sentisec in the path of production traffic.

For the attack class Sentisec defends your agents against, see the threat model.

Credentials

Your Sentisec API keys. A key is shown to you exactly once, at creation. What the database stores is a bcrypt hash of it (cost factor 12) plus the last four characters so you can tell your keys apart in the dashboard. There is no plaintext copy anywhere, and no way — including for us — to recover a key you did not save. Keys are revocable from the dashboard; revocation takes effect on the next request.

Your upstream provider credentials. When you paste a provider key, it is encrypted before it reaches the database, using authenticated symmetric encryption (AES-128-CBC with an HMAC-SHA256 tag — the Fernet construction). The database column holds ciphertext only; the encryption key is held outside the database and read at runtime. You can rotate or delete a stored credential from your workspace settings at any time, and deletion removes the stored ciphertext.

Subscription-mode credentials are never held at all. When you route a CLI coding tool that authenticates with a personal subscription rather than an API key, your session token is relayed to the vendor and never persisted by Sentisec. See subscription mode for how that path works.

What Sentisec stores about your traffic

Be precise about this before you deploy, because the default is deliberately generous: request and response bodies are captured by default. That is what makes a session timeline useful — you can open a flagged session and read the prompt, the tools, and the response that produced the verdict.

What	Stored by default	Notes
Request metadata	Yes	Model, provider, status, latency, token counts, cost, streaming flag
Prompt and system prompt	Yes	Switchable off per workspace
Response content	Yes	Switchable off per workspace
Tool definitions and tool calls	Yes	Switchable off per workspace
Verdict records	Yes	The verdict and intervention for each evaluated step
Evidence bundles	On session close	Sealed evidence or an explicit recording failure; see the guarantee below
Administrative actions	Yes	Append-only audit log

If you do not want bodies stored, switch the workspace to metadata-only capture. Request metadata, verdicts, usage, and cost still flow — so the dashboard, analytics, and billing all keep working — and the prompt, system prompt, response, tool definitions, and raw bodies are simply never written.

Retention

Each workspace has a content-retention window (365 days by default). Once a request row passes that window, a background sweep removes the stored content — prompt, system prompt, response, tool definitions, and both raw bodies — and stamps the row with the time it was pruned.

The sweep never deletes the row itself. That is a deliberate choice: the row also carries tokens, cost, latency, model, provider, and status, and your spend history, request counts, and usage analytics are built on those columns. Deleting rows to honour a content-retention promise would silently rewrite your billing history. Pruning the content in place keeps every number you have ever seen intact while the bodies genuinely go away.

Evidence you can verify without trusting us

From 0.8: With evidence recording healthy and the session close received, every closed session yields a sealed record or a visible failure, never a silent drop.

Sealing runs asynchronously. This guarantee starts when the close is received: a workflow that never supplies a close has not established that outcome. A sealed record covers the activity received before its seal; later activity cannot alter it. Keep recording failures and unavailable status reads visible when reviewing a run.

Two properties let an auditor check a sealed bundle's integrity:

Hash-chained. The bundle's load-bearing sections are hashed in order, so a section cannot be altered or removed after the fact without breaking the chain.
Signed. A separate manifest carries the bundle's SHA-256 and an Ed25519 signature over it. An auditor recomputes the hash from the bundle and verifies the signature against the public key. If either step fails, the bundle is not trustworthy — and that is a determination the auditor makes independently, without taking Sentisec's word for anything.

Signing key pairs are generated out of band. In a deployment inside your own cloud account, the private key lives in your secret manager, and no Sentisec-operated system ever holds it.

Identity and offboarding

Hosted sign-in uses Clerk. SAML or OIDC enterprise connections require configuration for the organisation; workspace permissions come from the verified session token. A directory role change must reach that token before it changes the next request's permissions.

Directory deactivation and user deletion do not automatically revoke Sentisec workspace API keys. Revoke relevant keys explicitly as part of offboarding. See directory provisioning.

The audit log

Every administrative action — a key minted or revoked, a credential rotated, protection mode changed, policy changed — writes one row recording the actor, the action, the resource, the client IP, a redacted request payload, and the outcome. The table is append-only: application code never issues an UPDATE or a DELETE against it. The log is readable in the dashboard and can be pushed to your SIEM.

Deployment hardening

The production stack runs its application services — proxy, worker, dashboard, and this documentation site — with:

a read-only root filesystem, with a small writable tmpfs as the only writable path;
all Linux capabilities dropped;
restart: always, so a crashed service comes back rather than silently disappearing from the path;
platform secrets mounted as files rather than baked into images — provider platform keys, identity-provider and billing secrets, and database and cache passwords.

TLS is terminated at the edge with automatically renewed certificates. All public endpoints are HTTPS only.

Fail-safe defaults

Two behaviours are worth stating explicitly, because they are the ones that matter when something goes wrong:

Protection resolves to enforce. If a workspace's protection setting is missing, null, or unreadable for any reason, Sentisec resolves it to enforce, not to open. This avoids silently disabling enforcement after a failure to read that setting. This does not expand policy coverage.
CLI subscription mode requests approval by default on an internal error. If the hosted check fails while protection is enforced, your tool call is held for your approval instead of hanging. Calls continue in monitoring workspaces and in deployments without a configured database. Authentication failures never allow a call to proceed.

Reporting a vulnerability

Email [email protected] with a reproduction, the expected versus observed behaviour, and — optionally — how you would like to be credited.

We aim to acknowledge within one business day and coordinate disclosure with you before any release note references the fix. We do not currently run a paid bounty programme; good-faith research under this policy is welcome regardless.