Skip to main content
Nuphos is a shared workspace where AI agents learn your infrastructure, investigate issues, and operate production systems — under your team’s control. A few concepts run through everything else in these docs. Read this page once and the rest will make sense.

​
Teams

A team is the top-level container in Nuphos. Every connected account, agent session, plan, and memory belongs to a team. You create a team the first time you sign in, and you invite colleagues into it. Members have one of three roles:
RoleCan do
AdministratorEverything, including connecting/removing accounts and managing members
EditorRun the agent, manage conversations and plans, use connected accounts
ViewerRead-only access
Connecting cloud accounts and other integrations requires the Administrator role. See Teams & members.

​
Scopes & the workspace

Nuphos organizes everything you can see into a hierarchy of scopes: 
Team → Account (AWS, GCP, …) → Cluster / resource group → Resource
You navigate down into a scope (for example: your team → an AWS account → an EKS cluster → a pod) and the breadcrumb keeps your place. The workspace is tab-based, so you can keep several scopes open at once — an agent chat in one tab, a cluster’s pods in another.

​
The Agent

The agent is the center of Nuphos. You describe what you want in natural language — “why is the checkout deployment crash-looping?” — and the agent investigates and acts against your connected infrastructure using real tools (shell, cloud APIs, Kubernetes, skills). Two ideas make the agent safe to point at production:
  • It only ever uses credentials you select for that session (see below).
  • Anything that changes your infrastructure is proposed as a plan that a human approves before it runs.
See Agent sessions.

​
Plans & approvals

A plan is the agent’s proposal for a change. It contains an overview, the key decisions, and a tree of steps → jobs → commands, plus a risk and cost assessment. Nothing in a plan runs until a team member approves it. A plan moves through a clear lifecycle: 
proposed → approved (or rejected) → executing → completed (or failed)
Every approval is attributed and timestamped, giving you an audit trail of who let what happen. See Plans & approvals and Approvals & audit.

​
Memory

As you work, the agent records durable facts about your environment — service names, ownership, runbooks, how a deploy flows — as memory. Memory is shared across the team, so the next person’s agent already knows what the last one learned. You can review and prune what the agent remembers. See Agent memory.

​
Credentials & the IAM model

Nuphos never stores your long-lived cloud keys. Instead, you connect an account once by establishing a trust relationship, and Nuphos mints short-lived, per-session credentials on demand:
  • AWS — Nuphos assumes an IAM role in your account via OIDC web-identity federation. Each session gets temporary credentials that expire in ~1 hour.
  • GCP — Nuphos impersonates a service account you designate, minting access tokens that expire in ~1 hour.
On top of that, administrators can restrict any connected account to specific team members with a member allow-list, and the agent only sees the credentials explicitly selected for the current session. This is the foundation of least-privilege in Nuphos — see Access control and the IAM trust model.

Quickstart

Put these concepts to work in a few minutes.

Connect an account

Establish the trust relationship for AWS, GCP, and more.