Security

The system that watches your services is held to the bar it asks of them.

What PulseTrace stores, how it is protected, who can reach it, and how to tell us if you find something. Written to answer the questions a security questionnaire asks — plainly, and only about what is actually built.

Encryption

All traffic to and from PulseTrace is over TLS, terminated at the ingress with HSTS as part of the production configuration.
Monitor credentials (bearer tokens, API keys, basic auth, mTLS keys, OAuth client secrets, AWS keys), environment secrets, MFA seeds and integration secrets are encrypted at rest with AES-256-GCM under a key held only by the authentication service. The plaintext is shown once, at creation, and never returned again; the API and UI return a masked hint.
Passwords are hashed with bcrypt; recovery codes and session, agent and API-key tokens are stored hashed, so a database read does not yield a usable credential.

Authentication and access control

Email and password sign-in with progressive lockout on failed attempts and CAPTCHA on abuse; TOTP two-factor authentication for every member, optionally required organization-wide, and mandatory for PulseTrace platform administrators.
Sessions use opaque, hashed tokens in httpOnly, SameSite=Strict cookies with double-submit CSRF protection and both idle and absolute expiry.
Four organization roles — viewer, developer, admin, owner — enforced server-side on every route. API keys carry explicit scopes, optional IP allow-lists, environment restrictions and expiry, and can be rotated with a grace period or revoked instantly. Service accounts give automation an identity that survives staff changes.
AI clients reach PulseTrace only through OAuth 2.1 with PKCE, per-scope grants, a per-organization policy, and human approval for destructive tools. Every MCP call is logged.

Application hardening

The app serves a strict, per-request nonce-based Content-Security-Policy with clickjacking, MIME-sniffing and referrer protections — the same headers the product grades on your sites.
Every service runs as an unprivileged user in its container; the ICMP worker gets only CAP_NET_RAW as a file capability, never root.
Parameterized SQL throughout, request body size limits, per-key and per-organization rate limits, idempotency keys on mutating requests, and trusted-proxy handling of client IPs.
Services refuse to start with default or weak secrets, so a misconfigured deployment fails closed instead of running open.

Data handling and retention

PulseTrace stores what it needs to monitor: targets, configuration, check results (status, timings, assertion outcomes and, for HTTP, a bounded response excerpt), incidents, change records and audit events.
Retention is per plan and per organization — 3 days on Free up to 365 days on Pro and Enterprise for execution history; 3 days to unlimited for audit logs — with an organization setting that can shorten it further. See Retention.
Deleting a credential, environment secret, monitor or organization removes the underlying data; encrypted secrets are not subject to retention windows and go immediately.
Alert emails and webhooks carry monitor names, targets and the failure message. They never carry credentials; the generic webhook is signed with HMAC-SHA256 so recipients can verify origin.

Auditability

Every administrative action — membership, roles, keys, service accounts, destinations, policies, plan changes — is written to a searchable audit log with actor, action, time and source address.
API requests made with keys are logged per key with outcome; MCP sessions, tool calls and approvals are logged per client.
Incident state changes, acknowledgements and manual resolutions are attributed and timestamped on the incident.

Infrastructure

The platform is a set of Go services (authentication, monitoring API, scheduler, monitor workers, admin, MCP, billing, email) behind an ingress that terminates TLS, with PostgreSQL, a metrics store, a message bus and object storage — each isolated from the public internet.
Billing is handled by Stripe; PulseTrace never sees or stores card numbers. Webhooks from Stripe are signature-verified and replay-protected.
The platform administration console is a separate service on a separate origin with its own session model and mandatory MFA, so it can sit behind additional network restrictions without touching the customer-facing app.

Responsible disclosure

If you believe you have found a vulnerability in PulseTrace, email security@pulsetrace.app with the steps to reproduce. We acknowledge reports within two business days, keep you informed while we fix, and credit you if you wish. Please do not run automated scanners against the hosted service at volume, access data that is not yours, or disrupt other customers; the free tools under /tools are the right place to test a target of your own.

Compliance status

PulseTrace does not currently hold a SOC 2 report or ISO 27001 certification, and does not claim to. The controls above are what is built; we would rather describe them precisely than borrow a badge. Customers on Enterprise can request a data-processing agreement and a security review call.

Retention details →

See the grades on your own endpoints.

The SSL/TLS Security monitor applies this same scrutiny to your sites — A+ to F, with every finding listed.

Start monitoring free Grade a site now