Docs / Team and security
Access control
The layers that decide who can use which connected account, and what the agent is allowed to touch.
Pangea controls access in three layers. Together they answer three questions: who is this person, which accounts may they use, and what can the agent reach right now?
1. Team roles
Every member has a role: Owner, Admin, Member or Viewer. The role sets their baseline.
- Only Admins (and the Owner) can connect or remove connectors and manage members.
- Viewers can't use connected cloud accounts at all. Pangea issues cloud credentials and kubeconfigs only to Members and Admins.
- When an agent asks for cloud credentials, both the person who sent the message and the owner of the conversation must be Members or Admins.
2. The access list on each connection
Each team connection has an Access List that controls which team members can use it, including from their agents. An Admin opens it with Manage access on the connector's page.
- Most connections start open to every member: All members are allowed.
- A few start closed, allowing only the person who connected them. Upstash and Trello work this way, because their credentials can't be narrowed on the provider side.
- Admins can always use and manage every connection.
Pangea checks the list on every credential request from an agent. Even when an agent has an account selected, Pangea re-checks that the person it acts for may use that account before it hands over credentials.
Use access lists to keep production accounts to a small group while the whole team works with staging.
3. Per-conversation selection
Each conversation only has the connections that were selected for it, under Agent credentials in the composer. It can only select accounts its owner is allowed to use. The agent can't reach an account that isn't selected. See Agents and shared sessions.
Why this matters
These layers give you least privilege by default:
- A Viewer can't change anything.
- A member can only use the accounts their access lists allow.
- Each conversation is scoped to the credentials selected for it.
Federated cloud credentials are short-lived. Personal access tokens, API keys and OAuth secrets have their own lifetimes and revocation rules. See the IAM trust model.
Each agent run gets a short-lived Pangea token scoped to that run, not your general sign-in token. For control over changes, such as approvals and audit, see Plans and approvals and Auto Mode and Full Access.
Personal credentials and local sign-ins
Each member can connect their own GitHub, Linear, Gmail and Google Drive accounts in Settings → Account → Personal Credentials. The agent uses them when that person sends a message, and for automated runs in conversations they own.
- A personal account belongs to its owner. Sharing a transcript does not give that account to another participant.
- In a shared conversation, each turn runs with the sender's own permissions, not the owner's.
A local runtime or local command can also use sign-ins that already exist on its computer. Selecting connectors for a conversation does not sandbox those existing sign-ins. Share a computer only with people you trust with that user's access.