Access, encryption, staff controls, networks, secure code, vulnerability handling, logging, and security reports.
We host our main production service and data with Hetzner in Germany and Finland.
Some support services process a smaller set of data in other areas. See the provider list for those cases.
We use TLS in transit and add field-level encryption to sensitive database values.
OAuth tokens, API keys, email subjects, and selected headers use database encryption with a key kept outside the database. Passwords are not stored for connected Google or Microsoft accounts.
Not every stored field uses the same extra field-level layer. Hosting, database rights, private networks, and access controls protect the wider data set.
We use Auth0 for login and signed, secure, HTTP-only cookies for production sessions.
We check the signed-in user and the record owner on each protected route. Only an owner can start sharing.
Most records carry an Auth0 user ID or another owner link. The service checks that link before it reads or changes a record. A list owner can grant named access or create a public share link.
A public share link makes that selected item available to anyone who has the link. It does not make the whole account public.
A user must connect their own active work mailbox at the company's email domain.
We form a team from users with an active Google or Microsoft mailbox at the same work domain. We exclude public mail domains such as gmail.com and outlook.com.
An admin cannot connect everyone's mailbox in one step. Each person signs in and approves access to their own account.
Team views show professional links and activity signals, not email or meeting text.
A team view can show which teammate knows a person, relationship strength, shared paths, contact counts and dates, and LinkedIn or X connection signals.
It does not return message bodies or calendar event text. It also hides an email address unless the person viewing the result has their own source evidence for that address.
Only approved admins can use our production support and service tools, and only when the work requires it.
Admin routes require an approved admin identity. We record admin actions and show when support work acts for a user. We limit access to what the work needs.
Our policy requires individual accounts and MFA for key admin services, plus SSH keys for production servers.
GitHub, Vercel, Auth0, and Sentry access uses named accounts with MFA. Production server access uses SSH keys rather than passwords.
Staff may use admin rights only when their work needs them. Our policy bans shared credentials and production-data exports to local machines.
Our offboarding policy requires access removal within 24 hours when someone leaves or changes role.
The checklist covers GitHub, Vercel, Auth0, Sentry, production SSH, Slack, and Google Workspace. We also review recent access and rotate shared secrets when needed.
Ask us for the latest completed offboarding or access-review evidence if your assessment needs it.
We keep production secrets outside source code and use separate keys for sessions, OAuth state, tokens, and encrypted database fields.
Runtime keys and provider secrets come from environment settings. Build-only secrets use Docker secret mounts. Secret scanning checks code changes before release.
Some keys rotate through their provider; others need a planned manual rotation. We do not claim an automatic rotation system where one does not exist.
Public traffic enters through HTTPS. Core API, worker, queue, and monitoring services stay on private or host-local paths.
Caddy terminates TLS and sends traffic to the API on the internal Docker network. Redis and Celery do not publish public ports. Database connections require TLS.
The task-monitoring dashboard binds to localhost and needs an SSH tunnel plus its own login.
We validate route input with typed models and send user values to PostgreSQL as bound parameters.
The database layer does not place user text into SQL strings. Search patterns use dedicated escaping. Templates escape output by default, and central error handling keeps database details out of public responses.
Static security scans and tests check these rules before code can ship.
We scan LinkedIn and X archive uploads for malware before we accept them.
The scanner fails closed: if it cannot check the file, the upload does not proceed. Uploads stay outside the public web file area.
We record service, sync, login, admin, and security events and send selected errors to Sentry.
Secret-scrubbing rules remove known tokens, keys, and password fields before error reporting. Error context can still include an account ID or email when it is needed to find a fault.
Application logs keep operational and security events for about 30 days; key database audit records stay longer.
We do not log request or response bodies, passwords, authentication tokens, or email content. Logs can include an account email or ID when needed to trace a sync, login, admin action, or security event.
Server logs need SSH access. Database audit records need database access. Login and permission audit tables have no automatic purge in the current policy.
We gate code changes with tests, type checks, code scans, secret checks, and package checks.
We scan code, secrets, packages, and container inputs, then track fixes by risk.
Dependabot and GitHub secret scanning run continuously. Each change runs security linting and secret checks; the push gate runs package and static security scans. We also review core infrastructure packages each month.
Our policy targets 24 hours for critical issues, one week for high issues, 30 days for medium issues, and 90 days for low issues. We do not publish individual fixed findings on this page.
Email contact@graph.one with the details.
Include the affected page or API, what you observed, steps to reproduce it, and a safe way to contact you. Do not send live user data, passwords, tokens, or exploit other accounts.
We do not currently publish a separate bug-bounty program or promise a reward.
