K-Φ

Security & responsible disclosure

How to report a vulnerability in K-Φ, and what we commit to in return.
Last updated: 31 August 2026

Reporting a vulnerability

Email security@k-phi.com. English or French, both fine. Please include enough to reproduce the issue: the endpoint, the request, and what you observed. A proof of concept helps; a scanner output alone usually does not.

We acknowledge every report that describes a concrete, reproducible issue within 72 hours, and we tell you plainly what we conclude — including when we disagree with the severity, and why.

What we commit to

We do not take legal action against researchers acting in good faith under this policy.
We fix what is real, and we say so publicly if the fix matters to our users.
We credit you if you want to be credited, and we will confirm a disclosure timeline with you rather than impose one.
We do not run a bug bounty programme and do not pay for reports. We state this up front so no one spends time on a false expectation.

In scope

k-phi.com — the application and its authenticated MCP server (OAuth 2.1).
mcp.k-phi.com — the public, anonymous MCP analyzer.

Out of scope

Denial of service, volumetric or resource-exhaustion testing.
Social engineering of our staff, customers, or suppliers; physical attacks.
Anything that destroys, alters, or exfiltrates data that is not yours. If a proof of concept requires real customer data, stop and describe the issue instead — we will reproduce it ourselves.
Findings that only restate a scanner's output, missing security headers with no demonstrated impact, or best-practice recommendations without an exploitable consequence.
Vulnerabilities in third-party services we consume, which should go to those vendors.

A note on Dynamic Client Registration

Our authenticated MCP server implements OAuth 2.1 Dynamic Client Registration (RFC 7591) with an open registration endpoint. This is deliberate: it is how MCP clients such as Claude register themselves, and requiring an Initial Access Token would prevent them from connecting at all.

The protections that matter are elsewhere, and are in place: PKCE with S256 is mandatory (an authorization request without code_challenge is rejected, and code_verifier is required at token exchange); redirect_uri is checked against the client's registered URIs before any redirect; the consent screen always shows the host that will receive the data; registration is rate-limited; and clients that never obtain a token are purged. Reports on this endpoint are welcome, but please take these into account when assessing severity.

Machine-readable contact

Our security.txt (RFC 9116) points here.

Data protection

For questions about personal data rather than vulnerabilities, see our Privacy Policy or write to privacy@k-phi.com.