# Roles and access Who can see and change what in your organization and its goals, and how to grant, narrow and take back access. Canonical page: https://app.auto-lab.ai/docs/organization/access Access works at two levels: the organization, and each goal inside it. This page explains the roles at each level, how to give someone a goal, how agents are shared, and which keys can act for you. ## How access works Every grant has the same shape: - **Who.** A person, a group, an agent, or an email address that has not joined yet. - **A role.** A named set of permissions. - **Where.** The whole organization, one goal, or one agent inside a goal. - **Until when.** Optional. The grant ends on its own at that time. Three rules follow from it. - Roles only add. No role takes a permission away, so a group never removes what a person already has. Remove someone's direct grant and they keep whatever their groups still give them. - Owners and admins of the organization are admins on every goal. A goal grant cannot lower that. To limit what someone reaches goal by goal, make them a member of the organization first. - A grant that names one agent narrows who may use that agent. It never adds permissions of its own. ## Organization roles Each person holds one role in the organization. The role picker shows the names in the second column. | Role | Shown as | Can | |---|---|---| | Owner | **Account owner** | Everything, including deleting the organization and transferring ownership. Admin on every goal. | | Admin | **Account admin** | Everything an owner can do except delete the organization or transfer ownership: invite and remove people, manage groups, roles and API keys, create goals. Admin on every goal. | | Member | **Account member** | See the goals they are added to, directly or through a group, and use only the agents granted there. Cannot create goals in this organization. | To change someone's role, open **Organization settings › Members**, open the person and choose **Edit access**. To change several people at once, tick their rows and choose **Change role**. ## Goal roles Inside a goal, a person is either an admin or a member. | Role | Shown as | Can | |---|---|---| | Admin | **Project admin** | Everything in the goal: Chat, the Brain (agents, skills, memory, connectors, secrets, triggers and schedules), settings, who has access, and deleting the goal. | | Member | **Project member** | Open the goal and follow its work: Overview, Chat, Activity and Learning. Start and stop sessions with the agents granted to them. No changes to the Brain, settings or access. | > **Who can talk to the agent** > > Sending messages in a goal's Chat and answering the agent's questions need the admin role on that goal. Give > **Project admin** to anyone who should work with the agent day to day. ## Give someone access to a goal You need the admin role on the goal, or the owner or admin role in the organization. ### Open the goal's access In the goal, open **Settings › Access** and choose **Grant access**. ### Pick who Under **Grant to**, pick people or groups from the organization, or type an email address to invite someone new. Everyone you select gets the same role. ### Pick the role and agents Choose the **Role**, then which **Agents** they may use: **All agents** or **Only these…**. ### Set an end date if you want one Fill in **Expires** to make the access temporary. Leave it empty to keep it until you remove it. People invited by email wait under **Invited to this project** until they join. To change or end someone's access later, open their row and choose **Edit access** or **Remove access**. **Organization settings › Projects** shows the same list for every goal in one place. Someone who opens a link to a goal they cannot reach sees **Ask for access.** and can send a note with **Request access**. The request appears under **Asked to join** in the goal's **Settings › Access**, where any admin of the goal can **Approve** or **Decline** it. While you set up a goal, the goal brief also shows an **Access** line: **Only you** or **Everyone in your organization**. It records who the goal is meant for. It does not add anyone by itself, so grant access here. ## Agents are closed by default A goal member can use an agent only when a grant names them or one of their groups. With no grant, they can use none of the goal's agents. - **All agents** grants each agent the goal has at that moment. When the goal gets a new agent later, grant it to the members who need it. - Once an agent has any grant, only the people and groups it names can use it, goal admins included. Owners and admins of the organization are never limited this way. - Whoever can use an agent can also use the secrets and connectors it declares, but cannot edit them. ## Groups A group lets you grant access once instead of person by person. Attach a group to a goal with a role, and every member of the group gets that role on that goal. Pick the group under **Grant to** like a person. Groups live in **Organization settings › Groups**. Creating them is an enterprise feature. With SCIM, your identity provider can keep groups and their members in sync, including when someone leaves. ## Enterprise features If your organization has them, owners and admins also get: | Feature | Where | What it does | |---|---|---| | Custom roles | **Organization settings › Roles › New role** | A role with exactly the permissions you pick. Assign it like a built-in role, on a person or a group, across the organization or on one goal. It only adds permissions; there is no deny. | | Single sign-on and SCIM | **Organization settings › Identity** | Sign-in through Okta, Microsoft Entra ID or another SAML identity provider, with members created at first sign-in. SCIM keeps people and groups in sync. | | Audit log | **Organization settings › Audit log** | Every admin and agent action: who, what, where and when. Filter it, export it as CSV or JSONL, or stream it out through webhooks. | | Branding | **Organization settings › Branding** | Your logo, icon, favicon and product name for everyone in the organization. | Without them, those panes explain the feature and offer **Request a demo**. The built-in roles always work. ## Require two-factor authentication In **Organization settings › Settings**, owners and admins can turn on **Require two-factor authentication**. Members without a verified second factor are then blocked from protected actions until they add one in **Personal settings › Security**. API keys are not affected. The same section sets how long someone stays signed in, and when an idle sign-in ends. ## What an agent may do on its own A running agent passes two checks: the roles of the identity it runs as, and the permissions the goal manifest (`kortix.yaml`) grants that agent under `agents..kortix_cli`. It can only do what both allow, and neither widens the other. An agent whose manifest lists an action still cannot do it without the role, and an agent started by an owner still cannot do what its manifest leaves out. See [Goal manifest](/docs/developers/manifest). ## Access keys Two kinds of key let a program act in Auto Lab. | Key | Where | Acts as | Use it for | |---|---|---|---| | Personal access key | **Personal settings › Personal access keys** | You, with your roles and groups | The CLI, a script or a CI job that works as you | | Service account token | **Organization settings › API keys** | Its own identity, with only the access you grant it | CI jobs and integrations that should keep working after the person who made them leaves | - A personal access key belongs to one organization, and you can limit it to one goal. Creating one needs the owner or admin role in that organization. It stops working if you leave the organization. - A key is shown once, when you create it. Copy it then; a lost key has to be replaced. - Under **Key rules** in **Organization settings › API keys**, owners and admins can require an end date, cap how long a key may last and turn off keys nobody has used for a set number of days. See [CLI](/docs/developers/cli) for signing the CLI in, and [API and sign-in](/docs/developers/api) for apps that sign people in with Auto Lab. Auto Lab's own platform admins handle sign-ups, invitations and suspensions from a separate console, outside your organization's roles.