Permission & Access Control

How Permissions Work

AI Employees don't have their own independent permission level. Instead, they borrow the permissions of the person who is using them. This is called "running in someone's context."

Think of it like this: If you ask an AI Employee to do something, it can only do what YOU can do. If you can't access a project, neither can the AI Employee. If you can see a private workspace, the AI Employee can see it too (but only when you're using it).

This is a safety feature. It prevents the AI Employee from accidentally giving you access to information you shouldn't see.

Whose Context Runs – Manual vs. Autonomous

This is the most important thing to understand about AI Employees. The person whose context runs determines what the AI Employee can access.

In Manual Mode (Chat)

When you click "Run Skill" in chat, the AI Employee runs under YOUR context. This means:

  • It can only access what you can access

  • It can only perform actions you have permission to perform

  • It uses your integrations (like your Gmail or Slack account)

  • If you don't have access to a workspace, the AI Employee can't access it either

Example: You ask Alfred to draft an email. Alfred runs under your permissions. If you can't send emails from a certain Gmail account, Alfred can't either.

In Autonomous Mode (Triggers)

When a skill runs automatically (like on a schedule or when an event happens), the AI Employee runs under the context of the person who SET UP the trigger. This means:

  • If Sarah set up the skill, it runs under Sarah's permissions

  • It can only access what Sarah can access

  • It uses the integrations that Sarah has set up

  • If Sarah can't access a workspace, the skill can't access it either

Example: Sarah sets up a skill to automatically update tasks in Project 101 every Monday. The skill runs under Sarah's permissions. If Sarah can't edit Project 101, the skill can't edit it either. If you (who didn't set up the skill) try to run it, it still runs under Sarah's permissions, not yours.

Why This Matters

This context rule prevents data leakage. It makes sure the AI Employee can't accidentally share information with people who shouldn't see it. Even if the skill is shared with your whole team, it only has access to what the person who set it up can access.

Permission Inheritance & Constraints

AI Employees follow the same permission rules as human users in Motion.

What They Can Access

AI Employees can access:

  • Any workspace, project, or task that the context user has permission to access

  • Any document that the context user has permission to view or edit

  • Any private workspace that the context user has access to

  • Any integration or connection that has been shared with them

What They Cannot Access

AI Employees cannot:

  • Access workspaces, projects, or tasks that the context user cannot access

  • View or edit documents that the context user doesn't have permission to see

  • Access private data of other team members

  • Bypass workspace RBAC (role-based access control)

  • Escalate permissions (do something the context user couldn't do)

Permission Boundaries

Here's the key rule: An AI Employee can never do something that the person running it cannot do.

If you're a Member (not an Admin), the AI Employee running under your context is also limited to Member permissions. It cannot delete workspaces, change user roles, or perform other Admin-only actions.

If the context user doesn't have access to a specific project, the AI Employee can't access it either — even if other team members can.

RBAC Structure – Admin vs. Member

Motion has two main roles: Admin and Member. AI Employees inherit the same role-based permissions as the person whose context they're running under.

Admin Role

If the context user is an Admin:

  • The AI Employee can create, edit, and delete projects and tasks

  • It can change workspace settings

  • It can manage team members and permissions

  • It can access all workspaces and documents

Member Role

If the context user is a Member:

  • The AI Employee can create and edit tasks and projects (but not delete them)

  • It cannot change workspace settings

  • It cannot manage team members or permissions

  • It can only access workspaces and documents that the Member has been given access to

No Permission Escalation

This is critical: AI Employees cannot escalate permissions. They cannot do things that the context user cannot do. If a Member tries to use an AI Employee to delete a project (which only Admins can do), the action will fail.

Data Access & Isolation

AI Employees are isolated to prevent unintended data sharing.

Workspace Scope

AI Employees can only access data within the workspace where they're running. They cannot cross workspace boundaries unless:

  • The context user has access to multiple workspaces

  • The skill is configured to act in a specific workspace (like "create task in my private workspace")

User Context Isolation

Each AI Employee execution is bound to a specific user's context. The skill cannot access:

  • Private data of other team members

  • Workspaces where the context user lacks access

  • Connections or integrations not shared with the context user

  • Documents or tasks the context user doesn't have permission to see

Example: Data Isolation in Action

Let's say you have a team with three members: Alice, Bob, and Carol.

  • Alice has access to Project A and Project B

  • Bob has access to Project B and Project C

  • Carol has access to Project A and Project C

If Alice sets up an AI Employee skill to update tasks, the skill can only update tasks in Project A and Project B (what Alice can access). Even if the skill is shared with Bob and Carol, it still runs under Alice's context. Bob and Carol cannot use it to access Project C because Alice doesn't have access to Project C.

This prevents accidental data leakage.

Skill Configuration & Context

When you create a skill in the skill builder, you can tell the AI Employee where to act. For example:

  • "Create a task in Project 101"

  • "Update tasks in my private workspace"

  • "Send an email from my Gmail account"

The AI Employee can only perform these actions if the context user has access to those places. If you tell the skill to "create a task in Project 101" but you don't have access to Project 101, the skill will fail.

PreviousFoundationsNextOperating Rules & System Boundaries

Last updated

Was this helpful?