Security
Read-only,
by design.
You’re deciding whether to hand a stranger your billing data. Here is exactly how that access works — the same detail we’d want before connecting anything to our own accounts.
Access is read-only and least-privilege
Every connection uses the narrowest read-only access the provider offers, and each source’s connect page shows you the exact grant before you create it:
- AWS — a cross-account role you create, scoped to billing reads, locked to our connector principal with an external ID. No access keys of yours ever leave your account.
- Azure — a service principal holding only the Cost Management Reader role.
- Google Cloud — short-lived impersonated tokens against a viewer-scoped service account; your billing export is queried in place, in its own region.
- Oracle Cloud — a dedicated read-only user and group; our onboarding walks you through creating them specifically so you never paste an administrator’s key.
- OpenAI, Okta, Microsoft 365 — a provider-enforced read-only grant: OpenAI’s Admin keys support a Read Only permission, Okta’s app scope is narrowed to
okta.apps.read, and the Microsoft 365 app registration is scoped to read-only license data. - Anthropic, GitHub — these two don’t offer a scoped read-only credential at all; the key you hand over carries broader access by the provider’s own design. There, the boundary is enforced in our code instead: we only ever call cost- and usage-reading endpoints, never a write endpoint, and the connect page says so plainly before you create the key.
We can’t change your infrastructure
For cloud providers and most AI/SaaS connections, this is a structural boundary: the credential itself carries no write permissions, so Capitops is unable to change your infrastructure through it — not just unwilling. Anthropic and GitHub are the exceptions (see above): there, the boundary is enforced in our code rather than by the provider, and we hold to it exactly the same way. Either way, savings recommendations link you into your own provider’s console to act — nothing changes without you clicking there.
How credentials are stored
Connection credentials are envelope-encrypted with Google Cloud KMS before they reach the database. That database runs in Montreal (northamerica-northeast1), has no public IP address, and is reachable only over a private network inside our own VPC.
Cross-border reads are disclosed, per source
Storage is in Canada; provider APIs are read where the provider hosts them, which today means US endpoints for every supported source. Each connect page states its specific cross-border read before you connect — you never find out after the fact.
Payments never touch our servers
Checkout and billing run on Stripe. Card details go directly to Stripe; we store only your plan and Stripe’s subscription identifiers.
No long-lived keys in the pipeline
Deployments authenticate to our cloud through Workload Identity Federation — there are no service-account key files to leak, in CI or anywhere else. The same discipline we ask of your credentials, we apply to our own.
Where we are honest about maturity
Capitops is a young company and does not yet hold formal certifications like SOC 2 or ISO 27001. The platform underneath does — Capitops runs entirely on Google Cloud, which holds SOC 2, ISO 27001, and more. Those attest to Google’s infrastructure, not to Capitops itself, and we won’t pretend otherwise. What we offer instead is specificity: the exact access model above, disclosed grants on every connect page, and straight answers at hello@capitops.com. Formal audits are on the roadmap as the company grows.
Reporting a vulnerability
Found something? Email hello@capitops.com with the details. We read every report, respond quickly, and appreciate responsible disclosure.