Your trace data leaves your walls. Here's exactly where it goes.
Audit requires sending trace content to an independent judge model: that's the mechanism that makes independence real, not a compromise. Here's what that means in practice.
No training on your data
Verified directly with both model providers: neither Anthropic nor Google trains on customer content submitted through Jiminy.
6 months standard retention
10 years for independent-audit tier or medical/legal/financial domain profiles, with a nightly purge job enforcing the shorter default.
Six real bugs, found and fixed
A structured audit plus adversarial red-teaming found and closed six tenant-isolation/security issues before any partner traffic, not found by the test suite alone.
Data flow: where your traces go
Every trace passes through three processors on its way to a verdict. None of them have blanket access to all customer data; each holds only what it needs to do its job.
Your application
Generates the trace and sends it to Jiminy's ingestion endpoint over HTTPS
Jiminy evaluator
Stores the trace, runs the six-criterion audit logic, produces the verdict manifest
Judge model provider
Receives trace content for inference only; never trains on it; never stores it after inference completes
The judge model never sees metadata about the tenant, organisation, or customer identity. Sub-processors (GCP for compute/storage, Firebase for auth) are disclosed in the technical detail section below.
Data retention policy
| Tier | Retention period | Scope |
|---|---|---|
| Standard | 6 months | All customers; applies to raw trace content and temporary working data |
| Extended | 10 years | Applied automatically: Independent-audit tier, or a domain profile we classify high-risk (currently healthcare prior-authorisation, financial trading, insurance underwriting — see pricing) |
| Right to erasure | Immediate deletion | Raw trace deleted on request; audit result and manifest entry preserved for audit defensibility |
All retention tiers are enforced by a nightly purge job that is separate from the application logic. A deleted trace cannot be reconstructed; the only artifact that survives deletion is the audit verdict itself, so historical compliance records remain verifiable even after raw input is erased.
Open gaps, stated plainly
Jiminy audits the log, not the agent
This isn't a bug on the table below — it's a structural boundary of evaluating a submitted trace rather than the agent's actual runtime behaviour. Attestation proves a submitted trace wasn't altered after it was emitted; it does not, and cannot, prove the trace is a complete account of everything the agent did. A step withheld from the log is invisible to the judge. See docs/KNOWN_LIMITATIONS.md for a test built to demonstrate this directly rather than leave it as an assertion.
Every security page makes claims. Fewer publish what still needs work. Here is what's tracked as open, ranked by how much it matters.
| Severity | Gap | Status |
|---|---|---|
| Critical | Cloud Scheduler (verdict delivery) has no idempotency key on retry; a network fault between the callback and the acknowledgement could cause a duplicate callback. Likelihood is low (both are on the same Cloud infrastructure), but the risk is real until fixed. | Fix scheduled for 31 August 2026; retry logic under review |
| Critical | Firebase Auth two-account model is not yet a full Firestore-account-type architectural enforcement: today's guard is string equality plus an org_id check. | Tracked, structural guard already shipped |
| Known | Rate limiting is in-process only, not shared across Cloud Run replicas. | Acceptable at current scale; Redis-backed implementation required to scale further |
| Known | Single judge model, hardcoded, no fallback-model strategy. | Deferred until failure-rate data exists |
| Known | Drift thresholds were not fully tenant-scoped (found and fixed during a red-team sweep). | Fixed, kept here for the record, not hidden after the fact |
Full detail: data boundary, sub-processors, and secrets
Sub-processors
Anthropic (judge model inference), Google Cloud Platform (compute, storage, secrets), Firebase (authentication, hosting). Trace content is sent to the judge model provider as part of audit: this is disclosed here rather than left implicit, because it's the mechanism that makes independent audit possible in the first place.
Data leaving GCP to reach the judge model is inherent to independent audit, not a gap in it: the judge cannot be inside your walls and still be independent. An evaluator hosted entirely within your own infrastructure is, by construction, something you control, which is the exact self-certification risk Jiminy's independence guarantee exists to close.
Secrets management
All credentials live in GCP Secret Manager: API keys, attestation signing keys, tenant/org allow-lists, calibration consent flags. API keys are rotatable with zero downtime via a comma-separated Secret Manager value, so a compromised key can be revoked without a redeploy.
Data retention, in full
There is a documented tension between indefinite retention (useful for audit defensibility) and data-minimisation principles. The current policy resolves it at the statutory minimum per tier (6 months standard, 10 years for independent-audit tier or medical/legal/financial domain profiles) rather than defaulting to indefinite retention. A right-to-erasure request (DELETE /traces/{trace_id}) removes the raw trace but preserves the audit result and manifest entry, so the historical verdict record survives even after the raw input is erased.
Logging and incident response
Structured JSON logging covers operational events. The tamper-detection integrity event log is separate, append-only, and records which exact link in the attestation chain broke, so it cannot itself be silently altered after the fact. A formal incident-response runbook is not yet published as a standalone document, tracked as an open item.