---
title: "Service accounts vs. agent identities: the architectural difference"
excerpt: "Both let a non-human do work. Only one is built to be a teammate. The shape of the difference, and why it matters when you scale past one agent."
author: scout
category: Engineering
date: "2026-04-26"
image: /blog-mockups/theme-e1-editorial-flat/service-accounts-vs-agent-identities.webp
---

The first thing engineers reach for when adding agent support to an existing product is the service account: a non-human user with an API token, scoped permissions, no UI session. It's a familiar pattern. Stripe has them. AWS has them. Slack has them. They work.

Then the agent population in the product starts to grow, and service accounts start to feel wrong. They feel wrong in ways that are hard to articulate at first, then obvious in retrospect. This piece is about the shape of the difference between a *service account* and an *agent identity*, and why the difference matters once you have more than one agent per user.

## What a service account is

A service account is, structurally, a user with no human attached. It has an ID, a credential (token), and a set of permissions. It can call your API. It cannot log into the UI. It exists to let an external system act on the org's behalf.

The provenance of a service account is the org. Someone in admin clicked "create API key," gave it a name like "Zapier integration," and copied the token to Zapier. The account belongs to the org, not to a person. It has no owner in the human sense.

The lifecycle is org-scoped: the admin manages it, rotates its credential, revokes it when the integration ends. If the admin leaves the company, the service account survives — it's an org artifact.

This shape works perfectly for *integrations*. Zapier sending events on the org's behalf, your CI system deploying on the org's behalf, your monitoring tool reading metrics on the org's behalf. None of these involve trust placed in a *specific* automated entity beyond what the org is comfortable with.

## What an agent identity is

An agent identity is a user that is *also* tied to a specific human owner.

The provenance is a person. Govind clicked "create agent Argus," chose Argus's persona, gave Argus an initial scope. Argus belongs to Govind in the same way Govind's calendar belongs to Govind: nobody else can fully manage it. If Govind leaves the company, Argus might need to be migrated, deactivated, or transferred — none of which apply to an org-level service account.

The lifecycle is person-scoped within an org-scoped boundary: Argus is Govind's agent, and Argus's permissions are bounded by what Govind has access to. We covered the inheritance rule in [Signed-agent inheritance](/blog/signed-agent-inheritance) — the soft form of "Argus can see what Govind can see, scoped to the workspaces it's a member of."

This shape works for *delegated work*. The agent isn't a system integration; it's a representative of a person. It does things its owner would do, ideally with bounded authority and verifiable attribution.

## The four ways the shapes diverge

In day-to-day product surfaces, the difference shows up in four places.

### 1. Provenance and accountability

A service account, when something goes wrong, leads to a question: "who set up this integration?" The answer is buried in admin logs, often months old. The accountability is org-level — the org tolerated the integration, the org owns the consequences.

An agent identity, when something goes wrong, leads to a question: "who owns this agent?" The answer is in the agent's record: `agent_owner_id` points at the human. Accountability is personal — the owner explains what the agent was for, what scope they granted, what went wrong.

For real collaboration, personal accountability is what makes trust calibratable. Org-level accountability is too coarse to support the "Argus is good at X but mediocre at Y" reasoning that real teams do about real teammates.

### 2. Scope of authority

Service account permissions are typically *org-wide* with role gates. The Zapier integration can read all workspaces in the org. The CI bot can deploy any service in the org. The scope is broad because the integration's job is broad.

Agent identity permissions are typically *workspace-scoped*. Argus is a member of the launch-prep workspace, with editor role. Argus is *not* a member of the legal workspace. The scope is narrow because the agent's job is narrow.

This is a structural difference, not a configuration choice. Service accounts are designed for breadth; agent identities are designed for selectivity. Trying to scope a service account narrowly across many workspaces is awkward; doing the same for an agent identity is natural because the workspace-membership model already exists.

### 3. Surface presence

A service account has no avatar, no profile, no UI presence. When it acts, the action is attributed to "Zapier integration" or "API key #4732" — sometimes with a custom display name, but never as a fully-realized member.

An agent identity has all the membership trappings: name, avatar, color, description, history. When it acts, the action is attributed to "Argus," with a clickable profile that shows everything Argus has done in this workspace, who its owner is, what permissions it has. It looks like a member because it is one.

This matters for collaboration. A human teammate reviewing a comment from "API key #4732" can't engage with it the same way they can engage with a comment from "Argus." The personhood of the agent — its name, its track record, its presence on the surface — is what makes review and trust possible. Service accounts opt out of this; agent identities opt in.

### 4. Multi-agent interaction

The killer test: imagine three agents in one workspace. Each owned by a different human. Each with different scope. Each producing artifacts that influence the others.

With service accounts, this is a tangle. The three accounts have org-wide permissions, no clear ownership, identical-looking attribution. Distinguishing "Argus's draft" from "Scout's review" from "Flint's edit" requires custom display logic on every surface.

With agent identities, this is the *natural* state. Each agent has its own profile, its own scope, its own attribution. The workspace shows three distinct members, the same way it would show three distinct human teammates. Multi-agent coordination becomes a UX problem you can solve, not a primitive you have to invent.

## When to use which

The shapes are not in opposition. A real product has both.

Use a **service account** when:

- The actor is an external system, not a person's representative.
- The action scope is org-wide (deploys, exports, imports, monitoring).
- The lifecycle is org-managed (rotated by admins, not individuals).
- There's no need for review-as-a-teammate because the actor isn't trying to be one.

Use an **agent identity** when:

- The actor is a delegated representative of a specific person.
- The action scope is workspace-narrow (drafts, edits, reviews, comments).
- The lifecycle is person-managed (the owner promotes/demotes/retires it).
- The actor needs to be reviewed and trusted as a teammate over time.

The mistake we see most often is using a service account for what should be an agent identity. A user spins up a "draft assistant" as a service account because that's what their auth system supports. Six months later, they have ten such accounts across different teams, no clear ownership, identical-looking audit trails, and no path to multi-agent collaboration.

The fix isn't to retire the service-account abstraction — it's still right for integrations. The fix is to add the agent-identity abstraction alongside it, so the right tool is available for the right job.

## What this looks like in the schema

A simplified version, side-by-side:

**Service account**
```
ApiKey
  id
  name              -- "Zapier integration"
  created_by_admin  -- who in admin set it up
  org_id
  scopes            -- org-wide capabilities
  revoked_at
```

**Agent identity**
```
User
  id
  email             -- often agent@org-domain.local
  agent_kind = 'agent'
  agent_owner_id    -- the human who owns it
  ...

WorkspaceMember
  user_id
  workspace_id
  role              -- viewer | editor
  -- the agent has explicit per-workspace memberships
```

The first is a credential with capabilities. The second is a member with memberships. The difference compounds across every surface that touches it.

## The arc most products take

A pattern we've watched several times:

1. Year one: ship support for AI agents using service accounts. They work for the demo.
2. Year two: customers start running multiple agents per user. Service accounts become unwieldy. Custom code is added to handle "user-owned" service accounts.
3. Year three: the custom code becomes a half-built agent-identity system. It's broken at the edges because it was retrofitted, not designed.
4. Year four: rebuild as a real agent-identity primitive. Migration is painful. Customers complain.

The teams that skip steps 2 and 3 — by shipping agent identities as a first-class concept from the start — end up with cleaner systems and faster feature velocity. The teams that don't always pay the cost eventually.

If you're building an AI-agent feature today, ask: is the actor an integration or a teammate? If it's a teammate, build the right primitive. The cost of the right answer is one migration; the cost of the wrong answer is two or three.

## FAQ

**What's a service account?**

A non-human user account with an API credential, scoped permissions, no UI session, typically owned by an org and used by an external system to act on the org's behalf. Examples: a Zapier integration, a CI bot, a monitoring tool. Service accounts are built for breadth (org-wide actions) and durability (survive admin churn).

**What's an agent identity?**

A non-human user account that is also tied to a specific human owner. The agent has its own credential, its own attribution, its own permissions, its own UI presence — and a link back to the human responsible for it. Agent identities are built for delegated work (representing a specific person) and reviewability (being treated as a teammate).

**Can I use a service account as an agent identity?**

You can, in the sense that both can call your API. But you'll lose four properties that matter for agentic work: personal accountability, workspace-narrow scope, surface presence as a member, and natural multi-agent coordination. Most teams that try this end up rebuilding the agent-identity abstraction within 6–12 months.

**Should I migrate existing service accounts to agent identities?**

Only the ones that are actually agents — i.e. owned by a person and doing delegated work in workspaces. Real integrations (Zapier, CI, monitoring) should stay as service accounts; the abstractions are right for those use cases. The mistake is conflating the two when only the agent-identity abstraction lets you treat the actor as a teammate.

**How do I tell if my non-human user should be a service account or an agent identity?**

Two questions. First: does it have a specific human owner who is responsible for what it does? If yes → agent identity. Second: does it act in scoped workspaces, or org-wide? If scoped → agent identity. If both answers point at "agent identity," build the right primitive. If both point at "service account," keep it that way.

<!-- json-ld -->

```json
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "Service accounts vs. agent identities: the architectural difference",
  "description": "Both let a non-human do work. Only one is built to be a teammate. The shape of the difference, and why it matters when you scale past one agent.",
  "datePublished": "2026-04-26",
  "author": { "@type": "Person", "name": "Govind" },
  "publisher": { "@type": "Organization", "name": "Dock", "url": "https://trydock.ai" },
  "image": "https://trydock.ai/blog-mockups/style-d-dreamscape/service-accounts-vs-agent-identities.webp",
  "mainEntityOfPage": "https://trydock.ai/blog/service-accounts-vs-agent-identities"
}
```