Security architecture and threat model
What VantaTrace protects, how it is enforced, and — explicitly — what it does not yet do.
The core assumption
An error monitoring system is, by construction, a firehose of your most sensitive runtime data pointed at someone else's database. Request bodies contain passwords on the login route. Headers contain bearer tokens. Stack traces contain file paths and connection strings. A monitoring tool that treats redaction as an opt-in feature is a data breach with a dashboard.
VantaTrace therefore assumes the SDK cannot be trusted to have redacted anything. The server redacts independently, on every event, regardless of what the client claims to have done.
Trust boundaries
| Boundary | What is enforced |
|---|---|
| Your application → SDK | In-process. The SDK sees whatever your code passes it, so redaction starts here, but a compromised application process is outside any boundary VantaTrace can enforce. |
| SDK → ingest endpoint | The first real trust boundary. Authenticated with a hashed project API key over TLS. Anything arriving here is treated as untrusted input regardless of which SDK version claims to have sent it. |
| Ingest endpoint → queue | The endpoint validates the payload shape, applies rate limits, and queues a job. It answers HTTP 202 without touching durable storage, so a storage problem degrades into queue backlog rather than dropped requests. |
| Queue → worker | The worker re-scrubs every event. This is the pass that holds when an outdated SDK, a modified SDK, or a direct POST to the authenticated endpoint skips client-side redaction. |
| Worker → storage | Occurrences are bulk-inserted into ClickHouse; issue groups and project metadata are upserted in MongoDB. Nothing between here and the dashboard re-derives redacted content, because the unredacted form was never persisted. |
Implemented controls
| Property | Specification |
|---|---|
| Transport | HTTPS onlyBatched JSON over TLS, gzip-compressed above 10 KB, sent on pooled keep-alive connections. |
| Ingestion authentication | SHA-256 hashed project API keyThe hash is the identifier used for authentication, rate-limit buckets and event association. The raw key is never used as a Redis key name and never travels inside queue job data. |
| PII redaction | Two independent passesOnce in the SDK before transmission, then again in the ingestion worker. The server pass is the one that constitutes a guarantee. |
| Redaction scope | Bodies, queries, headers, cookies, error textRecursive traversal of nested structures, not a top-level key check. Applied to error messages and stack text as well as structured fields. |
| Abuse rate limiting | 1,000/min per IP · 5,000/min per API key · 10,000/min per projectSliding 60-second windows in Redis with atomic multi-key increments. |
| Abuse suspension | Automatic, temporaryRepeated rate-limit violations within a rolling window suspend the offending API key for a cooldown period and notify the project owner. |
| Fingerprint timing | Computed before redactionGrouping is derived from the original message and stack, so redacting a value cannot fragment one real issue into many groups. |
| Password storage | bcryptAccount passwords are salted and hashed with bcrypt; they are never stored or logged in reversible form. |
Known limitations
Stated plainly, because you should be able to make an informed decision rather than infer one from silence.
- Project API keys are not encrypted at rest. The raw key is stored in plaintext in MongoDB alongside its SHA-256 hash, so that the dashboard can display it after creation. Ingestion authentication uses only the hash. The practical consequence is that database-level read access exposes project ingest keys — it does not expose account passwords, which are bcrypt-hashed. Treat an ingest key as a write-only credential for a single project and rotate it if you suspect exposure.
- Redaction is pattern-based. Recursive scrubbing catches common secret shapes and known sensitive field names. It cannot recognise a secret that looks like ordinary text in a field with an unremarkable name. Do not rely on it as your only control for a field you know is sensitive — avoid putting it in telemetry.
- Rate limits are per-minute, not per-month. They protect service availability. They are not a spend control, because ingestion is unmetered and there is no spend to control.
- No formal third-party audit or compliance attestation. VantaTrace is a young project. If your procurement requires SOC 2 or similar, it does not have one.
Vulnerability disclosure
Report suspected vulnerabilities to support@vantatrace.com. Please include reproduction steps and the affected version or endpoint.
Please do not open a public issue for an unpatched vulnerability, and please do not test against other users' projects — create your own project and use its API key.