Security is part of the telemetry design
Last updated September 2026
ContextPulse is engineered from the ground up to help engineering teams observe MCP servers without treating raw prompts, tool arguments, or end-user data as the default telemetry model.
1. Data Minimization by Default
The ContextPulse SDK defaults to bounded, recursively redacted payloads. Common sensitive keys (passwords, auth tokens, bearer credentials, API secrets), credentialed resource URLs, and binary/base64 blobs are scrubbed in memory before telemetry is transmitted across the wire.
Our metadataOnly mode omits arguments and results entirely; full capture mode is strictly opt-in and remains bounded by depth and byte limits. Your server retains total sovereignty over what it transmits.
2. Redact Before Data Leaves the Process
Scrubbing occurs inside your own server's runtime process. Use the SDK's explicit dotted paths, custom redact keys, and beforeSend event hooks to enforce application-specific data compliance.
Payloads are capped by bytes, depth, breadth, and string length, with structured markers for omitted content. If an unusual debugging scenario requires richer inspection, access policies and audit logging must be established first.
3. Keys and Workspace Boundaries
Ingest keys are strictly scoped to a workspace and should always be stored in environment variables or cloud secret managers (AWS Secrets Manager, HashiCorp Vault). Ingestion keys can be rotated or revoked at any time from the dashboard with zero server redeployment required.
4. Encryption & Transport Isolation
All telemetry is encrypted in transit using TLS 1.3 and at rest using AES-256. Furthermore, telemetry operates on an asynchronous background worker thread: if our ingestion cluster is momentarily unreachable, your server’s MCP tool calls continue executing without latency penalties or interruptions.