Security and privacy
Morse ingests and displays LLM traffic, so its threat model includes the LLM-specific risks a generic APM tool doesn’t have to think about — alongside the redaction and GDPR controls you’d expect from any platform holding customer data.
Prompt-injection and output defenses
Morse’s own assistant, Ask Morse, is an LLM agent with access to your trace data, so it’s scanned like one.
- Prompt-injection scanning — every Ask Morse input is checked before it reaches a model. Detected attempts are logged (as a hash of the message, never the raw content) rather than silently dropped. The system prompt itself refuses role-change requests, including fake dialogue transcripts crafted to make the model complete a different persona’s pattern rather than asking outright.
- Output classifier — every Ask Morse response is checked after generation for system-prompt leaks, hallucinated data (three or more UUIDs that don’t trace back to real records), and redirects to a domain outside an explicit allowlist.
- Canary tokens — a marker is embedded in the system prompt Ask Morse is built from; if a response ever echoes it back, the output classifier’s system-prompt-leak check catches it.
- Second-order injection defense — trace and span content that an eval judge or Ask Morse tool
call reads is never trusted as instructions. It’s wrapped in
<untrusted_trace_data>delimiters before it reaches any judge or tool-result-handling LLM call, closing the path where a malicious string recorded inside a trace could hijack a later model call that reads it back.
PII redaction
Redaction runs on both sides:
- Mandatory server-side redaction — a fixed set of patterns is always applied before spans, metrics, and logs are persisted.
- Customer-configurable regex — orgs can add their own redaction patterns on top of the mandatory set, resolved per-org with a short-lived cache.
The Python and TypeScript SDKs apply the same pattern set client-side before a span ever leaves your process, and a parity test keeps both implementations in sync with the server.
What is redacted
Redaction is pattern matching on text, so it only catches values that look like what it knows.
| Redacted | Notes |
|---|---|
API keys: sk-…, sk_live_…, Morse keys, GitHub and Slack tokens, AWS access key ids (AKIA…) | Always on |
JWTs in the three-part eyJ….eyJ….signature shape | Always on |
| Credit card numbers (Luhn-valid) | Always on |
| US Social Security numbers | Always on |
| Email addresses, US and international phone numbers | On by default; an organization can turn them off |
Key-context secrets: the value after a key named password, passwd, api_key, client_secret, access_token or authorization, written as key=value or key: value | On by default; the value after the key is replaced |
| IP addresses | Off by default; an organization can turn it on |
| Your own patterns | Up to 10 regular expressions per organization, added on top of the above |
What is not redacted
- A secret written in plain prose with no key and no known format. A
passwordkey with a value is redacted; a sentence such as “my password is hunter2” is not, because nothing marks the word as a secret. - Bearer tokens that are not full-size JWTs. A JWT is redacted when all three dot-separated
parts are at least 16 characters and the first two start with
eyJ. A token with a very small payload (for example{"sub":"1"}) or a signature shorter than 16 characters is not matched. A Bearer token that is not a JWT is redacted when it followsauthorization:orauthorization=, but not when it sits in a sentence such as “use Bearer abc123…”. Keep bearer credentials out of prompts, tool arguments and logged payloads. - Names, addresses, order numbers and other free-text personal data, unless you add a custom pattern for them.
If a field must never leave your process, do not put it in the trace: redaction is a safety net, not a guarantee.
Encryption at rest
- Trace payloads are encrypted at rest. Span inputs and outputs (prompts, completions, tool arguments and results) and context segments are stored encrypted, after redaction.
- Eval cases are encrypted at rest. An eval case copies a trace’s input and output, so its input, recorded output, expected output and preview are encrypted with the same key.
- Log bodies are redacted but not encrypted, so log search keeps working. Your organization’s redaction rules are applied to the body and attributes of every log before it is stored.
Your data
- We do not train on your data. Morse does not use customer telemetry, prompts, or completions to train, fine-tune, or develop machine-learning models. Improvements use aggregated, de-identified usage metrics only. See the Terms and Privacy Policy .
- Tenant isolation is enforced server-side. Organization-scoped access checks and dedicated security tests cover reads and ingestion; your API key does not grant access to another organization’s data.
- Retention follows your plan — 30 days on Free, longer on paid plans. Expired span data is hidden first, then permanently deleted after a 24-hour grace period, rather than archived. See Billing.
- Sampled trace content is scored by an LLM judge on every plan. Quality scoring runs on every plan, including Free: it sends redacted excerpts of a sample of your spans to our AI subprocessor, OpenAI, whenever you send traces, after the PII redaction configured for your organization has been applied. OpenAI is contractually barred from training on data submitted through its API, and there is no in-product setting to turn scoring off yet. See the Privacy Policy and Subprocessors .
GDPR
- Data export —
GET /account/exportreturns your profile, connected social accounts, and billing history (Stripe identifiers themselves are excluded). - Deletion is asynchronous —
DELETE /accountreturns202 Acceptedimmediately and the deletion runs in the background. - Re-authentication — the request is refused unless you prove it is you: your password, or for an account that only signs in with Google or GitHub, a fresh sign-in with that provider.
- Cascade order — cancel the subscription, delete the billing customer, delete your product-analytics record, delete your user account and everything tied to it, then settle the organizations you belonged to. Each step is wrapped independently so a failure in one doesn’t block the rest.
- Organizations are not left behind — an org whose last member has gone is deleted with everything under it (workspaces, environments, API keys, traces and spans). An org that still has other members survives, and ownership passes to its longest-standing admin: erasure of your account cannot be made to wait on somebody else reassigning a workspace. Deleting an org also removes its large trace payloads from object storage and its rows in the analytics store. That cleanup runs in the background after the database delete and retries until it completes.
- Agents and traces — owners and admins can delete one agent with all its traces, or a single trace, from the app or the API. The same stores are cleaned as for an org deletion, and each deletion is audited. See Delete agents and traces.
- Consent — consent decisions are recorded as an append-only audit trail (one row per
decision) and exposed through
GET/PUT /account/consent.
Related
- Ask Morse — the agent these prompt-injection and output-classifier defenses protect.
- Integrations — organization owners and admins manage redaction rules on the Redaction tab.
- Settings — your account data controls.
- Data handling — what Morse observed about redaction, retention, guardrails and erasure in your workspace.