Back to CloudJaeger
Trust & Security
Trust & Security
How CloudJaeger protects your data and your cloud. Built for the security and procurement teams who review us before we ever touch an account — read-only by design, with every stored cloud credential encrypted.
Encryption
Your data is encrypted at rest, and in transit across the public internet.
- At rest: the database and its automated backups are encrypted with AES-256 under an AWS KMS key.
- In transit: TLS 1.2 or newer between your browser and our load balancer (TLS 1.3 preferred); HTTP is redirected to HTTPS. Inside our private network the load balancer forwards to the application over plain HTTP.
- Stored cloud credentials are additionally encrypted at the application layer before they ever touch the database.
Data residency
Application data is hosted in the EU.
- Primary hosting region: AWS Europe (Frankfurt) — eu-central-1.
- The CloudJaeger database and its backups stay in-region.
- Apart from deliveries you set up yourself — alert channels, webhooks, scheduled exports and emailed reports, which go where you point them — the only data that leaves the region is the narrow, validated LLM context described below (sent to a US-based model provider).
Least-privilege access
We connect to your cloud with read-only, scoped permissions. An AWS connection holds no standing key; on Azure and Google Cloud we hold the read-only credential you issue us, encrypted.
- AWS: a customer-owned IAM role you create from our CloudFormation / Terraform template — read-only, scoped to cost & inventory APIs. We assume it with short-lived STS credentials, so the connection stores no long-lived AWS access key.
- Azure: a read-only service principal you create. We store its client secret, encrypted at the application layer (AES-256-GCM) before it reaches the database; rotate or revoke it in Microsoft Entra ID at any time.
- Google Cloud: a read-only service account. We store its JSON key, encrypted the same way; disable or delete the key in Google Cloud at any time.
- A scheduled export to your own storage is separate from the connection: it stores the credential you give it — an AWS access key pair for an S3 bucket or a Snowflake stage, a Snowflake token, or a BigQuery service-account key — encrypted the same way. An S3 export that uses an IAM role stores no key.
- You can revoke our access at any time — delete the AWS role, or revoke the Azure or Google Cloud credential — independent of CloudJaeger.
Secrets handling
Secrets are managed by AWS Secrets Manager, never committed or logged.
- Database URLs, API tokens, and signing keys live in AWS Secrets Manager and are injected at runtime.
- Application logs carry no credential values — secrets are never passed to a log line, and ops-event and sync-failure messages are redacted on top — and no external error-monitoring service receives them today.
- No customer cloud credentials are written to logs, ever.
Safety posture: we advise, your team makes the change
CloudJaeger is read-only. We surface savings, forecasts, and recommendations — we do not change your infrastructure.
Every recommendation is presented with the evidence it rests on. This build has no execution path: nothing is applied to your cloud, with or without an approval. There is no silent autopilot.
- Autonomous execution is not available: the two modes that would touch your cloud are locked in this build (below). If it is ever offered, it will be opt-in, under a written mandate you sign, as the Terms describe.
- Recorded actions are written to a hash-chained activity log (who did what, when): each entry commits to the one before it, so an edit, a deletion or a reordering shows up when the chain is verified. Coverage is not universal: some actions do not write to the log. Until the chain is keyed with a secret held outside the database, someone with database access could rewrite it undetected, and this deployment does not hold that key yet. No chain can show that its newest entries were removed. Owners and admins run the check in the product, in Settings › Activity Log (sign-in required); it reports the exact range it verified. Activity log (sign-in required).
- Access to your account is read-only. The one write our role can make is opt-in: with the detailed-bill (CUR) add-on, Athena writes its query results under a CloudJaeger prefix in your own CUR bucket.
Autonomy modes — none of them applies a change
The full range of what CloudJaeger can do — and, just as clearly, what it will not. Four modes are live today; the two that would touch your cloud are locked.
- Observe Live
- Read-only visibility.
- Advise Live
- Ranked recommendations with evidence.
- Dry-run Live
- Rehearses the exact action against your caps — nothing changes.
- Approve-to-apply Live
- A named human approves; you make the change; CloudJaeger tracks and measures it.
- Armed (with approval) Locked
- One approved action at a time, inside an owner-signed mandate.
- Autonomous (within mandate) Locked
- No per-action approval — only inside a narrow, expiring, capped mandate; reversible actions only.
This build has no execution path: nothing is applied to your cloud, with or without an approval. Approving a recommendation records a decision; nothing is applied.
Access model
Role-based access control inside your workspace.
- Owner / admin / member / viewer roles scope what each teammate can do. They do not narrow what anyone can see: every member of a workspace, viewer included, sees all of its spend.
- Every workspace is isolated from every other: each query is scoped to the workspace that issued it, so one customer can never read another's data.
- Enterprise SSO sign-in (SAML / OIDC) is built and switched off during the beta, until it passes our security review. SCIM 2.0 provisioning is built and stays off with SSO until the same review; once single sign-on is switched on for a domain your workspace has verified, SCIM provisions into it.
- The audit log is restricted to owners and admins.
Data handling
What we collect, and what we never send anywhere.
- We read cost & usage data and resource inventory metadata — not the contents of your workloads.
- Our LLM provider receives only validated recommendation summaries, for the explanations you opt in to, and the pricing questions sent to the pricing API — never credentials or raw line items.
- Our LLM provider operates under API terms that do not permit training on data we submit.
- See the full subprocessor list for every third party and exactly what each one processes.
Compliance roadmap
Where we are today — stated honestly. These are plans, not certifications we hold: no audit is under way, and our legal documents are drafts pending legal review.
SOC 2 Type IIPlanned
We are preparing our control set for a future SOC 2 Type II audit. No auditor is engaged yet and the observation window has not started — we do not claim SOC 2 compliance. We'll publish the report if and when an audit completes.
ISO/IEC 27001Planned
On our roadmap to follow SOC 2. No certification is claimed today.
GDPRDPA in draft
Our Data Processing Agreement is a draft pending legal review — ask us for the current version, or read it on the DPA page.
Vulnerability reports
Email hello@cloudjaeger.com to report a security issue or request our latest documentation.
Product support
For product questions, account issues, or beta feedback, email hello@cloudjaeger.com. Vulnerability reports belong with the security contact above.
Policies & documents
Our legal documents are drafts pending legal review. Your team can read them before you connect an account.
