← All Docs
Operations
Security
Key hashing, payload limits, TLS enforcement, and the privacy architecture.
Key hashing, payload limits, TLS enforcement, and the privacy architecture.
Brume is designed around a single principle: privacy by architecture, not by policy. The service is built so it cannot store or log request payloads, even by accident. This page describes the controls that enforce that and the rest of the security boundary.
A rate-limit check carries three fields: a namespace, an identifier, and a cost. There is no message body, no payload, no content. Because there is nothing to store, there is no payload store, no payload log, and no payload leak surface. This is an architectural invariant, not a configurable option.
Identifiers are yours to choose. If your identifier is a user ID, that is a correlation key, not personal data in transit — and it lives only in ephemeral Redis counters with window-bound lifetimes. If you would rather not send it, use identifier_type: ip or route and let the gateway derive the identifier server-side.
https://api.brume.run.These bounds keep a single abusive client from inflating memory or counter state.
Block and allow lists are evaluated inside the same atomic Lua script as the rule, before any capacity is consumed. A blocked identifier costs you nothing; an allowed identifier cannot be denied. Use them for abusive clients, credential-stuffing sources, or trusted internal callers that should never be throttled.
During soft launch: no SOC 2, no HIPAA BAA, no GDPR Article 28 DPA, no customer-managed keys. Regulated workloads should contact legal@brume.run before integrating. See the Acceptable Use Policy for the details.
Security reports: security@brume.run. We have no bug bounty program at this scale; we will credit you in the changelog if you want.