# Security integration package

## Credential handling

- Keep `clientSecret` exclusively in a server-side secret manager such as Azure Key Vault.
- Never embed credentials or bearer tokens in JavaScript, mobile applications, source control, URLs, screenshots, or logs.
- Use a separate API consumer for each client application and deployment boundary.
- Rotate credentials immediately after suspected disclosure and on the schedule agreed with VinQuery.
- Redact `Authorization`, `clientSecret`, and `jwtToken` values from diagnostics.

## Authentication and transport

Request a JWT from `/connect/token` using JSON and audience `vinquery:api:decisioq`. Send the returned `jwtToken` as `Authorization: Bearer ...`. The API validates issuer, audience, signature, and lifetime. TLS certificate validation must remain enabled.

The current DecisioQ policies authorize authenticated API consumers; the API does not presently advertise OAuth scopes. Do not manufacture scope claims in client code.

## Data minimization

Send only fields required for the decision. Avoid personal, regulated, or secret data unless the applicable decision contract and customer agreement explicitly require it. Treat decision inputs, outputs, and explanations according to their business sensitivity.

## Explanation boundary

The provider-neutral `explanation` object is optional and is `null` when unavailable. It is explanatory only; the deterministic decision result is authoritative. Applications must not treat generated explanation as the decision engine's source of truth.

## Security assurance artifacts

Architecture diagrams, penetration-test summaries, subprocessor lists, retention/deletion terms, privacy terms, and compliance attestations are commercial/governance artifacts. They require approval and should be shared through a controlled trust channel rather than invented or bundled as public claims.