Manage project members and access
Enterprise Tier
Membership decides who can work inside a project and what they can do there. Because a project is the isolation boundary, its member list also controls who can see its models, keys, and Model Context Protocol (MCP) configuration. This guide covers adding members, the roles available, and the deliberate separation between project access and data-plane operations access.
Access in Agent Router is layered. Project access governs the logical configuration of a single project; data-plane access governs the physical infrastructure that runs gateways. The two are kept separate so that application teams can manage their own project without being able to touch runtime capacity, and infrastructure operators can manage capacity without being able to change a project's models or policy.
Persona: Platform operator or project administrator working in the Admin Dashboard.
Estimated time: 5--10 minutes per project.
Outcomes
By the end of this guide:
- The users who should work in a project are added as members with an appropriate role.
- The difference between project access and data-plane operations access is understood.
- Members can find and switch into the project using the project switcher.
Prerequisites
- Administrator access to the project, or organisation-level administrator access.
- The project already created. See Create a project and grant models.
- The user accounts to be added already present in the organisation. Onboarding users is covered in Onboard developers and issue keys.
Step 1: Add members to the project
- Open the project's Members view.
- Add each user who should use the project.
- Assign a role: member for those who consume the project, or admin for the project owners who manage its configuration and membership.
Membership is per project. A user added to one project gains access to that project only, and a user may belong to several projects without any relationship between them.
Step 2: Confirm access through the project switcher
Members find and move between their projects using the project switcher at the top of the application.
- Confirm the added user can open the project switcher and see the project in the list.
- Note that the whole application re-scopes to the selected project: its API keys, models, and MCP views all reflect the project currently in context.
A user who does not see a project in the switcher is not a member of it, and access is granted by adding them in Step 1.
Step 3: Keep project and data-plane access separate
Project roles do not grant infrastructure permissions.
- Project admins manage the project: members, models, MCP, policy, budgets, and agent configuration.
- Data-plane operators manage the physical runtime: gateway provisioning, capacity, health, and rollout, covered in Deploy and register a data plane and Manage multiple gateways on a data plane.
Granting a user project access does not give them data-plane operations access, and the reverse is also true. Audit records distinguish logical project changes from physical data-plane and gateway operations, so the two kinds of activity remain separately attributable. Audit review is covered in Audit platform activity.
What to do next
- Issue a project-scoped API key: give members a credential for the project's gateway. See Issue a project-scoped API key.
- Onboard developers and issue keys: the organisation-wide view of users and roles. See Onboard developers and issue keys.
Where to go next