Skip to main content
Nuphos controls access in three layers. Together they answer: who is this person, which accounts may they use, and what can the agent do right now?

​
1. Team roles

Every member has a role — Administrator, Editor, or Viewer — that sets their baseline. Only Administrators can connect or remove accounts and manage members. Viewers cannot use connected cloud accounts at all: cloud credentials and kubeconfigs are issued only to Editors and Administrators. For an agent, the person sending the message and the owner of the conversation must both be Editors or above.

​
2. Member allow-lists on a binding

When an account is connected, an Administrator can restrict it to specific team members with a per-binding allow-list. By default, binding an account grants access to the person who connected it; the allow-list is how you widen or narrow that. This is enforced on every credential request from an agent: even if an agent has an account selected, Nuphos re-checks that the requesting user is allowed to use it before handing over credentials.
Use allow-lists to keep production accounts to a small group while letting the whole team work with staging.

​
3. Per-agent credential selection

Each agent only ever has the credentials you explicitly selected for it — and only for accounts you’re allowed to use. The agent can’t reach into an account you didn’t hand it. See Agents.

​
Why this matters

These layers compose into least-privilege by default: a Viewer can’t change anything, a member can only use the accounts they’re on the allow-list for, and each agent is scoped to exactly the credentials it needs. Federated cloud credentials are short-lived; PATs, API keys and OAuth secrets have their own lifetimes and revocation rules. See the IAM trust model. Each agent receives a short-lived, agent-scoped Nuphos token rather than your general login token. For control over changes specifically — approvals and audit — see Plans & approvals.

​
Personal credentials and local sign-ins

A member can connect personal GitHub, Linear, Gmail and Google Drive accounts. Personal token access is owner-scoped; a shared transcript does not transfer that account to another participant. Shared turns execute with the actual sender’s authorization rather than treating every message as the owner’s. A local runtime or local command can also reach sign-ins already on its computer. Conversation connector selection is not a sandbox around those pre-existing logins. Share a computer only with people you trust with that user’s access.