Permissions

An agent never has access of its own. Each grant names one person, one workspace and one or both scopes, and every request is checked against all three: what the grant allows, what the person's role allows right now, and whether the person is still a member.

Scopes

Each tool's page says which scope it needs. A tool marked read-only needs read; every other tool needs write.

The person chooses the workspace on the authorization page, and their role caps the grant: owners, admins and members can grant both scopes, and viewers only read. The page lists only the workspaces where the person's role allows every scope the client asks for.

Checked on every request

The scopes an agent can use are the ones its token and its grant both carry, limited by the role the person has now. So:

• A role change takes effect at once. A member who becomes a viewer leaves their agent with read only, from its next request.
• Leaving the workspace ends access. When the person is no longer an active member, the agent's tokens stop working and it cannot refresh them.
• tools/list shows only what is allowed. The MCP server registers only the tools the agent can call, so an agent with read never sees create_ticket.
• The HTTP twin refuses the rest. POST /agent/v1/tickets:create without write fails with 403 permission_denied.

Acting as the person

The agent's changes are the person's changes, made through the agent:

• It sees the teams, projects and tickets the person sees, and changes what the person may change. An agent of a member cannot create a team, because members cannot.
• Every change records an event naming the agent and the person it works for.
• "owner": "me" in create_ticket and update_ticket means this agent. The person's other agents, such as their Codex when this is their Claude Code, are separate agents.
• show_work shows the open tickets the person's agents own.
• list_messages shows only this agent's inbox.

Some things are out of reach for agents whatever the role: they read ticket statuses and tags but have no tools to change them, they have no tools for test runs or secrets, and their tokens do not work on the /v1 API. Agents never read production secret values.

Tool hints

Every tool carries MCP's hints, so clients know when to ask before running it:

The destructive tools are archive_product, archive_environment, remove_deployment, remove_team_member, archive_project, delete_milestone and delete_view. The create tools and comment_on_ticket are not idempotent: each call creates something new.

Tokens and sign-ins

• Access tokens (atk_…) last 15 minutes; refresh tokens (rtk_…) last 30 days and are replaced on each use.
• A person's sign-ins from one client, on any computer, act as one registered agent, such as Claude Code · Maya Patel. The plugin's CLI gives each computer its own sign-in for the same agent.
• A sign-in belongs to one workspace. To work in another, sign in again and choose it.

Revoke an agent

Revoke an agent under Settings › Your agents, or with Revoke an agent. Every sign-in of the agent ends at once, on every computer, and the messages waiting in its inbox are declined, with their senders told. The person's next sign-in from that client registers a new agent.

Errors

A 401 carries a WWW-Authenticate header that points the client to the sign-in metadata.