Service Accounts in Amp: workspace-owned accounts not tied to a single user
Amp introduced Service Accounts: workspace-owned accounts that are not tied to a single user. They carry their own API keys and third-party credentials, and the threads they create are visible to every workspace member, who can also send messages in them. The feature targets shared work such as PR review, documentation upkeep and automations kicked off from CI jobs.
Key points
- Service Accounts are created by workspace admins and are not tied to a single user.
- Each service account has its own API keys and third-party credentials.
- Threads under a service account are visible to workspace members, who can also send messages in them.
- Running `amp -ox` in CI with the service account's API key makes the resulting thread belong to the team.
- Always-on maintenance such as PR review or doc scanning can be set up as workspace-owned threads via Puck.
Amp added Service Accounts so that work belonging to a team no longer lives under one person's account. Created by workspace admins, a service account has its own API keys and third-party credentials, and every thread started under it is visible to all workspace members, who can also post messages in those multiplayer threads. The catch is that anyone in the workspace can drive them, so only credentials you would be comfortable handing to the whole team should be attached.
Two patterns stand out: workspace-owned threads that review new GitHub pull requests or rescan public documentation on a schedule (Amp sets these up through Puck), and CI jobs that invoke `amp -ox` with the service account's API key when a build fails. The thread then belongs to the team rather than to whoever wired up the pipeline, so automations survive staffing changes. Keep the service account's credential scope tight.
Real-world use
- An automation that opens a review thread on every new GitHub PR and keeps it accessible to the whole team.
- A workspace-owned thread that rescans public docs every 24 hours and @ mentions the owner of any stale page.
- A CI review bot that invokes `amp -ox` when tests fail to judge whether the break is a real regression or a flaky test.
- Maintenance work the team can keep steering even when the developer who set the automation up is on vacation or has moved on.
Why it matters
It moves automations and review workflows off individual accounts and onto the team, so a vacation or a departure no longer takes shared agent work offline.