Security

How we handle the data you trust us with.

This page describes what Sentinel does today, written plainly. It avoids certifications we don't hold and claims we can't back. If something you need isn't here, write in and we'll answer directly.

Last reviewed April 19, 2026·help@sentinels.in

Principles

Least-privilege integrations

Integrations connect through OAuth: you authorize Sentinel from a provider redirect and it receives scoped tokens - there are no keys to paste. HubSpot, Salesforce, Gmail, and Google Calendar are read-only; Slack runs as a scoped app that reads the channels its bot is added to and posts alerts. Each token is used only for the specific paths the product exercises - if a feature doesn't need a permission, we don't ask for it.

Read-only by default

Sentinel is a reporting layer over your source systems. We only read from connected CRMs and calendars; we do not write back to Salesforce, HubSpot, or Google Calendar. We do not send email from your domain, create meetings, or delete anything in a connected system.

Encryption at rest and in transit

All traffic uses TLS 1.2+. Integration tokens and webhook secrets are encrypted at rest in the database. The application itself is served over HTTPS with HSTS, a strict Content-Security-Policy, and a locked-down Permissions-Policy.

Signed, auditable webhooks

Outbound webhooks are signed with HMAC-SHA256 using a per-webhook secret. Every delivery attempt is logged with its response status, retried with backoff on failure, and visible in the dashboard for 30 days.

Deletion means deletion

Disconnecting an integration revokes and deletes its tokens from our database within 24 hours. Account deletion removes user-scoped records and triggers token revocation on connected providers where the API supports it.

Platform

Hosting: Vercel (edge + serverless). Regional failover handled at the platform layer.
Database: Managed Postgres with daily backups and point-in-time recovery enabled.
Authentication: Clerk handles identity. Email/password, Google, and SSO flows are managed by Clerk; we never see your password.
Monitoring: Sentry for application errors and performance. Structured logs carry a request ID from edge to database.
Rate limiting: Upstash-backed token bucket limiting on mutating routes to protect against abuse and runaway integrations.
Secret handling: Environment secrets are stored in the hosting platform's encrypted vault and rotated on a documented cadence.

Data handling

What data does Sentinel store?

The minimum needed to do the job: your profile from Clerk, your connected integrations' tokens and sync metadata, and the deal/event records we sync from connected CRMs and calendars. We keep AI-generated risk scores and short text summaries attached to those records.

Is my data used to train shared AI models?

No. Your data is never used to train shared or cross-customer models. Inference requests run against scoped provider APIs, and we send only the fields each call needs.

Who on the Sentinel team can access my data?

Sentinel is currently built and operated by one engineer. Production access is gated behind hardware-backed SSO and is used only to debug issues you report or to recover from an outage.

Where is data stored?

Production Postgres runs in a single managed region. All access is over TLS from the application layer; there are no public database endpoints.

What we don't claim

It's easy to paste a compliance badge on a site. We'd rather say what we actually have.

Sentinel is not SOC 2 certified. The audit is planned for later in 2026, and we will not claim it before the letter is in hand.
Sentinel is not HIPAA compliant. Do not use it to process protected health information.
Sentinel does not sign BAAs today. Enterprise agreements with custom terms are handled case-by-case - reach out if you need one.
Sentinel is operated by a small team. We optimize for transparency and fast response, not for having a 50-page trust center.