Access model

Access in connect0 is built on one idea: a principal — anything that can hold permissions in an account. Understanding principals, teams, and grants explains every "can this actor touch that resource?" decision the platform makes.

Principals: humans and agents

A principal is either a user (a human, backed by account membership) or an agent (a non-human automation you install). The ACL resolver, the audit log, and the grant editor treat them uniformly — same shape, different kind. This is what lets you scope an agent as precisely as a teammate. You manage both from /a/<slug>/settings/members, with agents also listed under their own detail surface.

Roles and account owners

Human members hold an account role. Owners can manage billing, members, and teams, and they bypass resource ACLs so they can never lock themselves out of their own account. Other members act within the grants they hold.

Two hard rules keep automation safe:

• Agents cannot be account owners. Owner-level blast radius (billing, removing members) always needs a human in the loop.
• Agents cannot grant access. Even an agent with an admin-level role on a resource can't hand access to another principal — only humans create grants. This stops a compromised agent credential from silently widening its own reach.

Teams and grants

A team is a named collection of principals — humans and agents can mix in one team or stay separate. Teams hold no permissions on their own; they're subjects you attach grants to. Manage them at /a/<slug>/settings/teams.

A grant ties a subject (a team, a user, or an agent) to a resource with a role. A resource with zero grants is open — every human account member can use it, which matches simple accounts where everyone wears the same hat. Add the first grant and the resource becomes restricted to its grantees (plus owners). Remove the last grant and it flips back to open. Connections are the first resource type to adopt this per-resource access editor.

Agents are default-closed

Humans are open-by-default; agents are closed-by-default. A freshly installed agent sees nothing in the account until you explicitly grant it access to a specific connection, project, or resource. The asymmetry is intentional: a runaway agent in a tight loop has a far larger blast radius than a person, so it starts with zero and you widen it deliberately.

Project scoping

Not everything is account-wide. Resources like connector instances, skills, and usage events are project-scoped, while membership, agents, and agent runs are account-scoped. Project scope is the natural place to separate one workstream's connections and data from another's.

Where to go next

• Audit — every grant and membership change is recorded with the actor who made it.
• Data and privacy — how the data behind these permissions is stored and protected.