Security

• Attempt metadata: route, exact configuration tuple, token and cache usage, latency, outcome and policy arm. Historical price epochs turn that journal into explicit cost evidence.
• Aggregate usage totals uploaded by the X-ray collector, which runs on your machine and reads your provider’s usage endpoints from there.
• Frozen public-reference, synthetic or CI corpora and immutable verification records. Content-bearing uploaded, staging and production corpora are refused in this release.
• Secret-manager references: the address of a credential, never the credential.
• On Door 1 only: a receipt per managed outcome, recording requested and served model, task class, decision, evidence label, optional applied-policy version, tokens, both prices, savings, fee and outcome, alongside the prepaid credit ledger. No table in this repository has a column for gateway prompt or completion content.
• On Door 1 only: Finest-held provider credentials, delivered to the gateway process by name from the deployment secret store, used to pay the provider on your behalf. Your own provider key stays in your environment, where the shim uses it only after a response proves Finest refused before provider dispatch.
• Account records: an email address, a workspace, a role, and the authentication records that keep a session alive. Production has no password to steal.

Where it runs. AWS US East (N. Virginia), us-east-1, in a private network. The database is not publicly reachable. There is no per-workspace region selection, and we say that plainly rather than implying residency we do not offer.

Keys and secrets. Policy signing keys live in AWS KMS and cannot be extracted by the application, which can ask for a signature and nothing else. Provider credentials are delivered to processes by name from the deployment secret store and are referenced elsewhere by opaque handle bound to one workspace and provider. Key material never appears in the database, in API responses, in audit payloads or in logs.

Identity. Sign-in is a one-time emailed link; there is no production password. Workspace keys are high-entropy, shown once, and stored as a digest. Browser roles and API-key scopes are separate authority systems, and a scope string cannot make a key behave like a human.

Integrity of the record. Evidence, receipt and audit journals are append-only by database constraint, and constraints make dishonest rows unwritable rather than merely discouraged. Deletion requires a dedicated role plus an explicit per-transaction flag that no request-path code sets.

In transit and at rest. TLS in transit; managed encryption at rest. Automated backups with a 14-day point-in-time-recovery window.

Supply chain and delivery. Deploys go through reviewed pull requests and a pinned CI pipeline with an OIDC-federated role rather than long-lived cloud keys. A secret scanner runs over the tree and over git objects, and treats any value from our own environment as an unconditional failure wherever it appears.

Error and log hygiene. Events sent to our error tracker are rebuilt from an allowlist, so request bodies, local variables, breadcrumbs, cookies and authorization headers are absent by construction rather than deleted by a rule that a future SDK version could outrun.

• Any mode that captures prompt or completion content is unavailable until per-workspace envelope encryption, consent and erasure are implemented and verified together. Supplying a key reference alone cannot enable it.
• The customer-local replay executor is not built. In the design, verification runs inside your environment and only non-content statistics come back; today the replay runs on the Finest worker, under recorded consent and a spend ceiling you set, over a frozen corpus you nominate. So the protection for content in this release is a refusal, not an enclave, and we will not describe it as one.
• Workspace erasure has a dedicated, separately privileged database path, but the audited self-service job that would drive it is not built. Deletion is an operator action on request, and the privacy policy says so rather than offering a button that does not exist.
• A full production restore drill has not been recorded. Automated backups and a point-in-time-recovery window exist and the procedure is written down; the drill is a launch item, not a completed one.
• The open-source shim and X-ray collector are not published to a package registry yet, so there is no repository link on this site. When they publish, the source and the install command appear together.
• No third-party audit, certification, penetration test report or trust-centre report exists today. We would rather have this sentence here than a badge that means nothing.

Report to [email protected]. Include what you did, what happened, and enough detail to reproduce it. We acknowledge within 3 business days, tell you our assessment within 10, and tell you when it is fixed, including when the answer is that you were right and we were wrong. There is no bug bounty; we will credit you by name if you want to be credited.

Safe harbour. If you follow this policy, make a good-faith effort to avoid privacy violations, data destruction and service interruption, use only your own test accounts and data, stop as soon as you have confirmed a vulnerability, and give us 90 days before public disclosure, then we will treat your research as authorised. We will not pursue or support a claim against you, including under the Computer Fraud and Abuse Act or equivalent law, and if a third party brings one we will make your authorisation clear. If you are unsure whether an action is in scope, ask first and we will answer.

In scope.

• finest.so and its console
• api.finest.so and gateway.finest.so
• The published Finest SDK and X-ray collector, once released

Out of scope.

• Denial of service, volumetric load testing, and anything that degrades the service for others
• Social engineering of our people, customers or providers, and physical attacks
• Findings that require a compromised device, a stolen credential, or a person acting against their own interest
• Missing best-practice headers, TLS configuration opinions and automated-scanner output with no demonstrated impact
• Vulnerabilities in a model provider’s own systems, which belong in that provider’s disclosure programme rather than ours

Testing against another customer’s workspace, or against a provider through us, is not research and is outside the safe harbour. The acceptable use policy draws the same line.

We will notify affected customers without undue delay, and within 48 hours of becoming aware of a personal data breach, with what is known at the time rather than waiting for a complete picture. Clause 10 of the data processing addendum is the contractual version of that sentence. An incident notice is not an admission of fault, and we would still rather send one early than one that is tidy.