Security
You’re handing us read access to your bills. Here’s exactly what that means.
Connecting a cost tool means giving it credentials to the systems that run your company. That deserves a straight description of what happens to them, not a badge. This page is that description. It ends with what we don’t have yet.
Read-only, always
Plutus never requests write permissions on your cloud accounts. It reads billing and recommendation data and nothing else. Acting on a recommendation stays with your team, inside your own change process. No third party gets the ability to alter your infrastructure.
Your credentials are encrypted before they land
Every third-party credential is encrypted with AES-256-GCM before it is written to the database, under a key held outside it. Once saved, no path in the product returns a secret to a browser. The connection screen can tell you a field is set without being able to show you what it is.
Your cost data is yours
It is never sold, and never used to train third-party AI models. Export it as CSV whenever you like, and if you delete your account it is removed rather than retained. That includes the time-series history, not just the login.
Reaching your cloud
- AWS is a role you deploy, not a key you paste
- Access is a cross-account IAM role in your own account, scoped to cost and recommendation reads, deployed by a Terraform module or CloudFormation template you can read first. You can revoke it from your side at any moment without asking us.
- An external ID unique to your account
- That role is bound to an external ID derived for your account alone, so the role you deploy cannot be assumed on behalf of anybody else. It is the standard defence against a confused-deputy attack, and not a shared secret across customers.
- Outbound requests are checked before they are made
- Anywhere the product calls a URL you supplied — a webhook alert destination, for example — the address is validated as a public HTTPS endpoint first, so an internal address cannot be used to make Plutus fetch something on an attacker’s behalf.
Signing in
- Two-factor on every plan, including the free one
- Authenticator app or emailed code, enrolled independently, with one-time recovery codes issued once and stored hashed. Turning a method off requires your current password. Nothing here is reserved for a paid tier.
- Trusted devices waive the second factor, never the first
- Choosing to remember a browser skips the code for thirty days on that browser only. The password, or the Google or GitHub step, still runs every time. Each device is a separate record you can revoke on its own, and changing your password revokes all of them.
- Single sign-on with Google or GitHub
- Available on every plan, alongside email and password. Enterprise directory integration via SAML is not shipped today.
Sessions
- Sessions end when you say they do
- A session lives in a cookie JavaScript cannot read, and is re-checked against the live account on every single request. Change someone’s role, remove them from an organisation, or deactivate them, and their access stops on their next request, not whenever a token would have expired.
Keeping accounts apart
- Membership is the source of truth
- Access to an account is a membership record with a role attached, not a field on your user. Switching between organisations re-issues your session with that organisation’s role, so permissions in one never leak into another.
- Isolation is enforced by the build, not by review
- Every route that takes an account identifier has to prove the caller belongs to it. That is not left to code review: a static-analysis rule runs on every pull request and fails it if such a route is added without the check, so the guarantee cannot be forgotten by accident.
- Three roles, enforced server-side
- Admin, member and viewer. The interface hides what your role cannot do, and the API refuses it independently. The screen is a convenience. The server is the boundary.
What is recorded
- An activity log your own admins can read
- Who invited whom, who connected a source, who changed a budget. All of it recorded automatically and readable by your administrators, kept for as long as your plan’s retention window. Internal support actions are logged separately and just as completely.
What you can remove
- Deletion means deletion
- Removing a connected source purges the cost history that came from it, not just the credential. Deleting your account cancels any subscription immediately and removes your data across both stores. Both are self-service; neither needs a support ticket.
- Retention is a number on your plan
- History is kept for the window your plan includes — thirty days on the free plan, up to three years at the top — and purged automatically past it, rather than accumulating indefinitely by default.
How the code is checked
- Secrets cannot reach the main branch
- A credential scanner runs on every pull request and blocks the merge outright. It is the one check with no override, on the reasoning that a leaked key is the failure that cannot be walked back after the fact.
- Static analysis, dependency and container scanning
- Code, infrastructure definitions and workflow files are scanned on every pull request; dependencies and built images are scanned nightly against fresh advisories, so a vulnerability disclosed after a release still surfaces.
- The live site is probed, and every release is inventoried
- An automated pass runs against the running application weekly, and each release publishes a signed inventory of everything inside the image. That is what makes it possible to answer “were we exposed to this?” about a component months later, from a record rather than from memory.
Where we are on formal certification
Plutus does not hold SOC 2 today. If your procurement process requires it, that is a real answer to have before a trial rather than three weeks into one, and it is why it’s written here rather than left for a questionnaire.
What exists in the meantime is everything above, plus the per-release inventory that a Type II report eventually needs a history of. That history cannot be created retroactively, so it is already being kept. SAML single sign-on and directory-driven provisioning are not part of the product today.
Found something?
Email security@plutus-cloud.com rather than opening a public issue. You’ll get an acknowledgement within three business days and an initial assessment within ten. You’ll also get a straight answer about whether and when it’s being fixed, including “we don’t think this is a vulnerability, and here’s why”. Anything touching tenant isolation, authentication or credential exposure is fixed in days rather than scheduled. We’ll credit you in the release notes if you’d like to be credited, and we’ll work to your disclosure deadline rather than asking you to sit on it indefinitely.
