Security
The credential model
The onboarding app never holds a customer credential at rest, and never reaches your cloud directly.
For AWS, Azure and Google Cloud there is no credential to hold. You authorise an identity that belongs to you, and Helias assumes or federates into it:
| Provider | What you authorise | How Helias signs in |
|---|---|---|
| AWS | An IAM role you create | Assumes the role, gated by an External ID unique to your organization |
| Azure | A service principal in your tenant, with no secret | Federated credentials, so no secret exists on either side |
| Google Cloud | IAM bindings on a service account provisioned for you | Workload Identity Federation, so no service account key is created |
Cursor and Anthropic offer no keyless option, so those two take an API key. The key passes through the onboarding app only in memory during the connection. It is never written to our database, never appears in a log, an error message or a toast, and comes to rest only in the environment dedicated to your organization.
One isolated environment per customer
Your access is held in an AWS account dedicated to your organization, and for Google Cloud a dedicated project as well. Helias never shares a collector, a service account or a service principal across customers.
That isolation is what makes the AWS External ID meaningful: the principal your role trusts belongs to your environment and no other customer's.
What we store
The onboarding database holds connection state only: which accounts, subscriptions and projects are connected, and what was verified at connect time. It holds no credentials.
State is partitioned per customer behind a data layer that injects your tenant into every query. No read path omits it.
What Helias never asks for
- Root or global administrator credentials.
- AWS access keys or secret keys.
- Google Cloud service account JSON keys.
- Azure client secrets or certificates.
- Any password, MFA code or session token.
- Write access of any kind, in any provider.
Signing in
Sign-in is federated through Google or Microsoft. There is no Helias password, and no one-time code. The authorisation code exchange happens on our server, so no provider token reaches the browser.
Your session is an encrypted, httpOnly cookie that expires after seven days of inactivity. It holds your email, your organization and which identity provider you used, and nothing else.
Signing in and being authorised are separate. A verified identity can sign in and still reach nothing: access to an organization's data comes from an allowlist entry that a person creates when your request is approved.
Auditing and revoking
Every action Helias takes in your cloud appears in your own audit logs, attributed to the identity you authorised: CloudTrail for AWS, Microsoft Entra ID sign-in and activity logs for Azure, Cloud Audit Logs for Google Cloud.
You can revoke that access from your own console at any time, with no notice to us. Deleting the CloudFormation stack, removing the service principal, or removing the IAM bindings each ends access immediately. Each provider page carries a Disconnecting section covering what disconnecting in Helias does, and what stays behind in your own account.