Summary
Add first-class AI service accounts to Plane CE: workspace admins can create bot identities that act on the v1 API through dedicated service tokens, with an explicit allow-list of what each bot may do (resource type + action, optionally scoped per project). Bots are backed by regular user rows (is_bot=True), so everything they create (work items, comments, ...) is ordinary data owned by a visible, auditable identity — but they can never log in interactively and are default-deny until an admin grants a scope.
Why should this be worked on?
Self-hosted CE users increasingly drive Plane from CI pipelines and AI agents (code review bots, ticket triage, status sync). Today the only options are:
- Personal API tokens — actions are attributed to a human, the token inherits all of that human's permissions (no least-privilege), and the integration breaks when the person leaves or rotates their token.
- Sharing one human account — worse attribution and audit trail.
What's needed is the standard "service account" pattern every mature tool has (GitHub machine users/bots, GitLab project bots, Jira service accounts):
- A workspace admin creates an AI account in settings — no email signup, no password, no onboarding flow.
- The account gets a service API token that is shown once and can be revoked by toggling or deleting the account.
- Permissions are an explicit allow-list (default-deny): e.g. "may create work items and comments in project X" — nothing more.
- The bot is visible and manageable like a regular member: workspace/project member lists, per-project add/remove, role editing — so project admins keep control of what a bot can touch.
- The bot's effective permission is capped by its owner's role, so a bot can never out-privilege the human responsible for it.
This unlocks safe automation and AI-agent integrations on self-hosted instances without weakening the permission model.
Summary
Add first-class AI service accounts to Plane CE: workspace admins can create bot identities that act on the v1 API through dedicated service tokens, with an explicit allow-list of what each bot may do (resource type + action, optionally scoped per project). Bots are backed by regular user rows (
is_bot=True), so everything they create (work items, comments, ...) is ordinary data owned by a visible, auditable identity — but they can never log in interactively and are default-deny until an admin grants a scope.Why should this be worked on?
Self-hosted CE users increasingly drive Plane from CI pipelines and AI agents (code review bots, ticket triage, status sync). Today the only options are:
What's needed is the standard "service account" pattern every mature tool has (GitHub machine users/bots, GitLab project bots, Jira service accounts):
This unlocks safe automation and AI-agent integrations on self-hosted instances without weakening the permission model.