Security and data handling

This page describes controls that apply to the public API and the CLI. For company-wide security practices and certifications, see Security on breachline.io.

Credentials

• Keys are hashed. Only a SHA-256 hash of each API key is stored. The plaintext is shown once, when the key is created or rotated.
• Authentication fails closed. A request without a verified credential is refused; there is no anonymous access to the API.
• Keys cannot mint keys. Creating or rotating a key needs an interactive, recently authenticated session.
• Key creation is notified. The account owner receives a security notification whenever a key is created.
• Lifetimes are capped. New keys expire after at most 365 days by default.
• Keep the CLI on HTTPS. The CLI’s tool endpoints refuse a non-HTTPS base URL (except a loopback address for local development), but the LLM gateway base in BREACHLINE_API_BASE is not checked, and your key is sent to it. Leave BREACHLINE_API_BASE unset, or set it only to an https:// URL you trust. See CLI configuration.

Tenant isolation

• Every request is bound to one verified principal: an organization, a user and, for keys, the key.
• Stored Responses objects, batches and batch files are scoped to the organization and user that created them, not to one key. Any key or console session of that same user in that organization can read, cancel or delete them; other users and other organizations get 404. Use a separate user, not a separate key, when stored objects must be kept apart.
• Idempotency claims are scoped to organization, user and key, so two tenants, or two keys of one user, never collide.
• Usage logs are scoped to the caller or to an organization the caller belongs to.

Data you send

• Prompts and completions. Requests are processed to produce a response. Usage logs record metadata only (time, endpoint, model label, token counts, status and latency), never prompt or response content.
• Stored responses. With store: true, a Responses object is kept for 30 days by default so it can be retrieved or continued. Delete it any time with DELETE /v1/responses/{id}.
• Batch files. Batch inputs and results are kept so you can download them, and are scoped to your user in your organization.
• Secrets in output. BreachLine removes its own credentials from model output: BreachLine API keys (bl_live_, bl_test_) and the platform’s provider keys are replaced with [REDACTED_SECRET]. By default, other secrets are passed through unchanged, including credentials discovered on a target during testing, because they are part of the findings. Treat model output as sensitive.
• Engines. Nebula routes requests across an engine matrix. Model ids are BreachLine product names; the serving engine is not part of the API.

Privacy and data protection

BreachLine’s privacy policy sets out how personal data is handled, including sub-processors, international transfers and retention periods. Data protection terms for customers are in section 10 of the Terms.

Testing responsibly

BreachLine is an offensive-security tool. Test only systems you own or are explicitly authorized to test, within the scope you confirmed. The console and CLI keep scope and approvals explicit; see Scope & oversight.

The rules for testing with BreachLine are in the Terms: Authorised use only and the Acceptable use policy.

Reporting a vulnerability

Report a vulnerability in BreachLine to security@breachline.io. The vulnerability disclosure policy, including its scope and safe-harbour terms, is on breachline.io/security, and the contact is also published in security.txt.

Availability

Service availability is covered in section 11 of the Terms.

This documentation site

• Fonts, icons and the API reference are self-hosted. Pages load no third-party scripts, set no cookies and run no analytics.
• Each page’s Content Security Policy allows connections only to this site.
• The API reference is static and read-only. It has no Try it feature and no request proxy, so you never type an API key into this site.