Ingest authentication
Choose JWT, mTLS, CIDR, identity binding, or an API key for the write path.
Authentication proves which sender is making a request. Authorization then checks whether that identity may write the selected model.
Available controls
| Control | What it proves or restricts |
|---|---|
| Generated or customer JWT secret | The sender possesses the configured signing secret |
| mTLS | The sender presents a certificate signed by a selected Client CA |
| CIDR allowlist | The request comes from an allowed source network |
| Identity binding | Values from payload, JWT, and/or certificate agree according to policy |
| API key | A programmable identity has ingest capability and model scope |
JWT secrets
ReportPlane can generate a secret or use a customer-provided secret. A generated secret should be copied at creation and stored securely. Stored configuration does not expose secrets again as plain text.
mTLS
Choose a Client CA and identity extraction settings. The TLS session is terminated by the ReportPlane runtime for ingest/query domains so the client certificate can be validated directly.
CIDR
CIDR is a useful additional restriction but is not a replacement for cryptographic identity. Empty allowed-IP lists are treated as no IP restriction, not deny-all.
Identity binding
Supported modes can compare payload identity with JWT claims, combine payload and mTLS identity, or require JWT and mTLS agreement. Configure the payload field, JWT claim, and certificate identity source deliberately.
Identity binding helps prevent a valid credential for one tenant or device from claiming another identity inside the payload.
API keys
An API key can have ingest capability, query capability, or both. For ingest, select allowed models and optional CIDRs. Use a separate key per application boundary.