Product · Security & Access

Find the savings. Never hold the keys.

Jetscale connects to your cloud environment to find savings. It never needs the keys to change it. Every integration, every user role, and every credential exchange is built around one principle: the smallest possible amount of access, granted in the most reversible way possible.

Read-only IAM roles No standing write access Per-business-unit RBAC

Read-only by design

List, describe, get, export. Never write.

Jetscale's core job is to analyze cost, usage, and resource data across your cloud accounts and recommend optimizations. It does not need, and is never granted, the ability to create, modify, or delete resources in your environment. Every cloud connection is provisioned with a dedicated, least-privilege identity scoped to read-only operations only. There is no standing write access, and no shared or long-lived credential sits between Jetscale and your infrastructure.

AWS

Jetscale connects through a cross-account IAM role rather than a shared access key. You create the role in your own account, and Jetscale assumes it temporarily using sts:AssumeRole, secured with a unique External ID that prevents any other party from assuming the same role (the "confused deputy" protection AWS recommends for third-party access). The attached policy is limited entirely to read operations: Cost Explorer, Cost Optimization Hub, Compute Optimizer, EC2, RDS, Redshift, DynamoDB, S3, ElastiCache, CloudWatch, ECS, EKS, and related services, built from Describe*, Get*, List*, and Export* actions only. No Put, Create, Delete, or Modify permission is ever requested.

Azure

Jetscale authenticates through a dedicated App Registration (service principal) that you create and control, using either a certificate or a client secret. Access is granted through built-in Azure roles: Reader, Cost Management Reader, and Monitoring Reader, scoped to the subscription level, or through an optional custom role for teams that want even tighter control. That custom role explicitly excludes sensitive actions such as listing or regenerating storage account keys, so even a compromised credential can't reach into your data plane.

GCP

Google Cloud connections follow the same pattern: a dedicated read-only identity, scoped to the cost, billing, and resource-inventory data Jetscale needs, with no permissions to modify or delete infrastructure.

Every new connection goes through a validation step before it goes live, confirming the permissions are correctly scoped and nothing more, and our team is available to walk through setup with your cloud or security team directly.

Secure credential exchange

Nothing sensitive travels in a single, unencrypted message.

Where a secret does need to change hands (an External ID, a client secret, a certificate thumbprint), Jetscale's setup process is built around out-of-band handling.

Generated By whichever side controls the value
Encrypted Before it is ever sent
Decrypted separately Password shared via a different channel

Role-based access for your team

Access that lines up with how you're actually organized.

Inside Jetscale, every person on your team is assigned a role for each business unit they need to work in, not an all-or-nothing account.

No Access

The user exists in the system but has no visibility into that business unit.

Viewer

Read-only access to that business unit's cloud accounts, cost data, and recommendations.

Operator

Can act on recommendations and manage day-to-day optimization work.

Admin

Full control over that business unit, including its users, cloud connections, and settings.

Because roles are assigned per business unit, a single user can be an Admin in one part of the organization and have no access at all to another, a natural fit for organizations that manage multiple teams, subsidiaries, or environments through one Jetscale account.

Account lifecycle & authentication

Always visible who has access, and who doesn't.

  • Active
  • Pending Activation
  • Terminated
  • Admin-controlled, always current.

Administrators can add or remove people at any time, and deactivating someone's access is immediate.

Jetscale never asks an administrator to see or set another user's password. Instead, access is granted by sending the user a secure password-reset link, which they use to set their own credentials directly.

Integrations you control

Authorized through the provider. Visible at a glance.

Connections to tools like GitHub and Azure DevOps (used to let Jetscale open pull requests for infrastructure changes it recommends) are authorized through each provider's own connected-app flow, not by pasting in a static token. You can see exactly what's connected at a glance, and disconnect it at any time from the same screen where you set it up.

Delivery

GitHubConnected-app OAuth

Delivery

Azure DevOpsConnected-app OAuth

Working with your security team

Let's get your security team what they need.

We know cloud access reviews don't stop at reading a page like this one. Our team is available to walk through the exact IAM policies, RBAC role definitions, and connection architecture in detail with whoever on your side needs to sign off. Reach out any time.

Book a Demo Talk to our security team

More on the platform

Go deeper on another layer.

Platform Overview

How connect, detect, fix, and verify fit together across the whole product.

Learn more →

Integrations

Terraform, GitHub, and your cloud console: fixes ship through tools you already use.

Learn more →

MCP

Give your own agents and IDE direct access to Jetscale's findings and fixes.

Learn more →