# Amp — Service Accounts

- Company: Amp (ampcode.com)
- Announced: 2026-11-03
- Category: capability-change
- Coverage: not counted
- Announcement: yes
- Group: announcements
- Source: https://ampcode.com/news/service-accounts
- Record: https://forck.live/items/31057-service-accounts
- Subject: Amp

Amp added Service Accounts, workspace-owned accounts that are not tied to a single user, so team work can outlive the person who set it up. Workspace admins create the accounts, which carry their own API keys and third-party credentials. Threads created under a service account are visible to other workspace members and are multiplayer, meaning members can send messages in them. Amp warns that because anyone in the workspace can drive those threads, admins should only assign credentials they would be happy bestowing on all workspace members. Amp names two patterns that fit: codebase review and maintenance, such as reviewing every pull request or keeping docs accurate, and programmatic work, such as a CI job that spawns a thread via amp -ox when a build fails. Using a service account's API key for that invocation makes the thread belong to the service account instead of whoever set up the pipeline.

## Evidence

Verbatim from https://ampcode.com/news/service-accounts:

> Amp now has Service Accounts. A service account is a workspace-owned account that's not tied to a single user.
> 
> Service accounts are created by workspace admins. They have their own API keys and third-party credentials.
> 
> Each thread created under a service account can be viewed by other members of the workspace. These threads are multiplayer too, so workspace members can send messages in them.
> 
> Since anyone in the workspace can drive a service account's threads, make sure to only assign credentials to it that you would be happy bestowing on all workspace members .
> 
> When to Use Service Accounts
> 
> Service accounts fit any work that belongs to the team rather than to one person. For example, threads with automations that workspace members want to have access to, even if the person who set them up is on vacation.
> 
> We've found two patterns where service accounts work especially well.
> 
> Codebase Review and Maintenance
> 
> Reviewing every pull request or keeping docs accurate is work that belongs to the team, not to a single user. When a service account owns that work, anyone on the team can step into its threads and steer them.
> 
> Here are some example prompts for setting that up via Puck:

---

Record: https://forck.live/items/31057-service-accounts
Catalogue: https://forck.live/llms.txt
Current issue: https://forck.live/feed.md