Security

Last updated: 19 April 2026

This page documents Signal Quadrant's security posture, how to report vulnerabilities, and what we already know about — so you don't have to dig.

1. Reporting a Vulnerability

Please email hello@signalquadrant.com with details. We aim to acknowledge within 72 hours.

A useful report includes:

• What you tested and how (request payload, tool name, expected vs actual response)
• Whether the issue is exploitable, theoretical, or a hardening suggestion
• Any proof-of-concept that does not require sustained traffic against the live endpoint

We follow RFC 9116 — see /.well-known/security.txt.

2. Security Posture

Two-system isolation

Signal Quadrant runs as two architecturally separate systems. The public MCP service (this site, the Worker, the public database) holds only data that is safe to publish: aggregate market benchmarks, pattern-library metadata, and pre-computed cohort statistics with a minimum sample size of n≥5 per bucket. Individual assessments, raw transactions, and proprietary scoring logic live on a separate, fully internal system that has no inbound network path from the public surface.

What the free tier returns

The free tier returns market context, not company-specific assessments. Aggregates only. Bucketed positioning, not exact rankings. Narrative pattern insights, not raw data-basis text. Cohort statistics, not individual records. A complete dump of the public database would yield only a small set of aggregate rows — useless without the underlying assessments and source data they were derived from.

Controls in production

• Rate limit: 20 calls/day per hashed IP (one-way SHA-256, never stored raw)
• Session quotas: a shared pool quota across sector-keyed tools (the same sector queried across tools counts once) and per-tool call ceilings for the rest. Designed to prevent extraction by cross-tool multiplication.
• Input sanitization: length caps, character-class enforcement, unknown-parameter rejection
• Sanitized error responses: any echoed input passes through the same filters as tool arguments — never raw user-supplied bytes
• Payload limit: 10 KB maximum request body
• Response integrity: HMAC-SHA256 signature on every tool response
• Security headers: HSTS preload, CSP, X-Frame-Options DENY, COOP/CORP, Permissions-Policy
• Framework non-disclosure: internal scoring section names, rule identifiers, and execution-band names are never returned in tool responses

3. Known Limitations

We ship known limitations rather than hide them. None of the items below permit access to private assessments or the proprietary corpus — they are honest disclosures about the public surface.

Rate limiting cannot distinguish Claude.ai users

All requests originating from claude.ai arrive from Anthropic's egress IPs, so the IP-hashed rate limit treats those users as one bucket. We accept this for the free tier; per-user limits will arrive with API-key authentication on the paid tier.

Client-side counter values are informational

Some response fields surface a remaining-quota number for the client's UI. These are informational only; the enforcement value lives server-side. Manipulating client-visible counters does not bypass enforcement.

Numeric context fields in tool responses

Some tool responses include structured numeric context alongside their primary output — for example, the funding-positioning tool surfaces sector-level context numbers next to its qualitative result. These are the same aggregates already exposed by the dedicated benchmark tools; extracting them via context fields yields nothing that a single direct call would not already return.

Funding positioning is qualitative, not numeric

The funding-positioning tool returns a qualitative position rather than a numeric percentile. This is intentional: a precise numeric percentile, repeatedly queried with varying inputs, would let a caller reconstruct the underlying distribution shape. A bucketed positioning prevents that. Per ADR-006, the public database stores aggregate bands rather than individual transactions, so the underlying data needed to compute an exact percentile is not present in the public surface at all.

4. Out of Scope

• Sustained traffic against the live endpoint. Please do not load-test, fuzz at scale, or attempt to exhaust rate-limit windows against production. Targeted single-request proofs are welcome.
• Extracting paid-tier data from the free tier. Paid-tier company-specific data is not present in the free tier infrastructure. There is nothing to extract.
• Findings against third-party infrastructure. Cloudflare, WorkOS (when the paid tier launches), and other vendors should be reported to those vendors directly.
• Reports based purely on missing best-practice headers. If a header is missing on a specific path, please include the path and a brief impact analysis rather than a generic scanner output.

5. What Is Not Public

The following are part of Signal's internal pipeline and are not reachable from any public endpoint:

• Individual assessment narratives, scorer flags, devil flags, or evidence sources
• Raw canonical assessment JSONs (build_<company>_data.json)
• Per-CIN keyed confidential data, individual director-DIN records, or individual funding transactions
• Internal scoring methodology, section names, or rule identifiers
• The private database holding the assessment corpus

If you believe you have found a way to access any of the above through the public surface, that is a serious finding and we'd like to hear about it immediately at the contact above.

6. Contact

Security: hello@signalquadrant.com

RFC 9116 record: /.well-known/security.txt