Skip to content
leancosts docs

Security and data handling

leancosts is built read-only. The posture below is enforced in code, not promised in a policy doc: it is the same architecture our own security review runs against. For the full legal documentation (DPA + security overview), email sales@leancosts.com.

Read-only by construction

Section titled “Read-only by construction”

leancosts connects to your cloud with read-only credentials and never writes to, mutates, or provisions anything in it. Every recommendation is a guided kit your own team runs, never a button that reaches into your account. Nothing executes without your team’s approval: two people by default; self-approval only where your workspace admin allows it, and always on the record, even when the autonomous loop is running. This is a property of how the system is built, not a setting you have to trust us to keep.

Least privilege: what we ask for

Section titled “Least privilege: what we ask for”

We request the narrowest read-only access that surfaces the savings, and nothing that can change a resource. The exact grants, split into required and optional, are in Connect a cloud account.

  • Azure trial: one subscription, Reader + Cost Management Reader only: cost and inventory metadata, not log contents.
  • Azure full estate: adds read-only roles you scope yourself (Log Analytics Reader for ingestion-cost analysis; optional Reservations, Backup and EA Enrollment readers, each safe to skip).
  • AWS: a read-only cross-account role (the AWS-managed ReadOnlyAccess plus a small Cost Explorer / CUR read policy, plus the AWS Marketplace agreement reads). Nothing that can mutate a resource.
  • GCP: viewer roles only (billing, asset, monitoring, and BigQuery read).

Encryption

Section titled “Encryption”

Cloud credentials are encrypted at rest with AES-256-GCM; every connection travels over TLS in transit. The encryption key is held outside the database.

Tenant isolation

Section titled “Tenant isolation”

Every organization’s data is isolated by Postgres row-level security. Each query is scoped to its organization at the database layer (not only by application filters), so one tenant’s data is unreachable from another’s session.

Where it runs

Section titled “Where it runs”

leancosts is hosted on Railway (the application and the Postgres database) with Cloudflare for CDN, static hosting, and off-site backups (R2). The application and the database both run in the United States. Data-residency terms are set out in the DPA.

No AI/LLM provider is configured in production, so no customer data reaches a model vendor today. If we ever enable one, it is named in the DPA first and stays opt-out per organization. The OpenAI and Anthropic connectors are not an exception: they read those vendors’ admin APIs for your own roster, token usage and billing (every call is a GET) and send nothing to a model.

Outbound addresses

Section titled “Outbound addresses”

Every call leancosts makes into your cloud leaves from a fixed set of three egress addresses. If your security team restricts access by source IP (a storage-account or Key Vault firewall, an AWS IAM aws:SourceIp condition, a GCP VPC Service Controls access level), these are the addresses to allow:

162.220.232.251
152.55.177.181
152.55.177.192

Two things to know before relying on them. They are fixed, but not dedicated: the hosting provider may assign the same addresses to other workloads, so an allow-list narrows exposure without being an identity check. The read-only credential you granted remains the control that matters. And the addresses change only with notice on this page.

Access ends when the relationship does

Section titled “Access ends when the relationship does”

When a trial expires or a tenant is deleted, access is revoked and the associated data is removed. You hold the off switch throughout: disconnecting a cloud or deleting your workspace stops all access immediately.