Should an AI agent have a role or a service account?
Both. They answer different questions. A service account (or API key) says what an agent can reach. A role says what the agent is for, which tools it should use, where it stops, and which organization owns it. An agent with only a service account has access but no accountability. That is how ghost agents are made.
Two different questions
| Service account / API key | Role | |
|---|---|---|
| Answers | What can this reach? | What is this for, and who owns it? |
| Holds | Identity + credentials + scopes | Responsibilities, tools, boundaries, reporting line |
| Owned by | Whoever created it, in practice | The organization |
| When the creator leaves | Still works, purpose unknown | Hand the role to someone else |
| Fixes | The access half of agent risk | The ownership half |
Identity and access tools are good at the left column. They can rotate, scope and revoke. They have no column for purpose, so they cannot tell you whether revoking a key just broke the weekly close. See AI agent identity and access management for the access half in depth.
Rendering diagram…
Read the diagram top down. Credentials hang off an agent, which holds a role, which belongs to the organization. When credentials sit at the top instead, everything below them is owned by whoever happens to hold the key.
What this looks like in agent.ceo
agent.ceo puts the role first. An agent is created inside an organization as a role, and there are 16 predefined roles or you can define a custom one:
curl -s https://agent.ceo/agents | grep -o "16 predefined roles"
Credentials are then scoped underneath the role. Organization API keys are created with specific scopes and can be revoked, after which they are refused. How agents are bounded in what they may touch is described in role-based access control.
The honest boundary
If you run two agents and you personally built both, a well-scoped service account is fine. You are the role definition. Roles start paying for themselves when there are more agents than one person can account for from memory, or when the person who built them might leave.
FAQ
Should an AI agent have a role or a service account?
Both, because they answer different questions. A service account or API key answers what the agent can reach. A role answers what the agent is responsible for, which tools it should use, where its boundaries are, and which organization owns it. An agent with only a service account has access but no accountability, which is how ghost agents are created.
Why isn't a service account enough to govern an AI agent?
A service account is an identity plus credentials. It has no field for purpose, responsibility or owner, so when the person who created it leaves, nothing in the account says what the agent was for or who should decide its fate. Credential tools fix the access half of the problem, not the ownership half.
What should an AI agent role define?
Its responsibilities, the tools it may use, its operational boundaries, its position in a reporting line, and the organization that owns it, so that handing over the role hands over the agent.
Related: What is the ghost agent problem?