Nuphos is designed so that it never holds a long-lived key to your cloud. You
establish a trust relationship once, and Nuphos mints short-lived
credentials on demand for each session. This page explains the mechanism for
each provider and why it’s built this way.
AWS — OIDC web-identity federation
Nuphos runs an OpenID Connect identity provider. When the agent needs AWS
access, the backend signs a short-lived OIDC token and calls
sts:AssumeRoleWithWebIdentity against the IAM role you created.
The token carries:
- Issuer:
https://nuphos.ai (its discovery document is published at
https://nuphos.ai/.well-known/openid-configuration)
- Audience (
aud): sts.amazonaws.com
- Subject (
sub): nuphos:team:<your-team-id>
Your role’s trust policy pins all three with a StringEquals condition. The
sub condition is the key isolation control: it ties the role to your team
specifically, so no other Nuphos team can assume it — the standard mitigation for
the confused-deputy problem. Nuphos also enforces that a given role ARN can only
be bound by one team.
| Value |
|---|
| OIDC token lifetime | ~5 minutes |
| Assumed session lifetime | ~1 hour |
| What Nuphos stores | the role ARN only |
Older connections may use a legacy static-connector principal instead of OIDC.
That path has no per-team sub condition, which is why OIDC web-identity is the
recommended method for new connections.
GCP — service account impersonation
For GCP, you create a connector service account in your project and grant the
Nuphos platform service account
(zeabur-byos-connector@zeabur-system.iam.gserviceaccount.com) the Service
Account Token Creator role on it. Nuphos then impersonates your connector to
mint short-lived access tokens.
| Value |
|---|
| Impersonated token lifetime | ~1 hour |
| What Nuphos stores | the service account email and project ID only |
Why short-lived and per-session
- No standing keys to leak. Nuphos stores only a reference (a role ARN or a
service account email), never a usable secret.
- Blast radius is bounded. Credentials expire in about an hour and are scoped
to the session that requested them.
- You stay in control. Trust is something you grant in your own cloud and can
revoke at any time by editing the role’s trust policy or removing the
impersonation grant.
Hardening
- Start the role/connector read-only and widen only as the agent needs it.
- Keep the AWS
sub condition intact — it’s what scopes the role to your team.
- Use member allow-lists to limit which people can use
sensitive accounts.
- Require plan approvals for changes.
