Service Accounts or OAuth Tokens for AI Agents: Which to Use

Use a service account when the agent does a company-owned task that no single person should own, such as working a shared queue or writing to a system of record. Use OAuth tokens when the agent acts for a specific person inside that person's own mailbox, calendar or files. Most real deployments use both, chosen per integration, because the right answer depends on whose action it is, how you need to trace it and how quickly you must be able to cut it off.

Key takeaways

• A service account is a company-owned identity that acts as itself. An OAuth token is delegated permission that lets the agent act as a person, within approved scopes.
• Service accounts make automated activity easy to spot in provider logs. OAuth activity looks like the human who approved it, so the agent needs its own log either way.
• Revoking a service account is one switch with a wide blast radius. Revoking an OAuth grant is narrow, but it can break silently when a person changes role or leaves.
• Scope is the biggest practical risk. Shared service accounts collect permissions over time, and OAuth scopes are often coarser than the task needs.
• Decide per integration, write the choice down with an owner, and test revocation before the agent goes live.

What is the real difference between the two models?

A service account is an identity that belongs to the company, not to a person. The agent authenticates as that identity using a credential the company holds, such as a key, a certificate or a workload identity issued by the hosting platform. Every permission is granted to the account itself, and every action is performed as the account.

OAuth is a delegation model. A person (or an administrator) approves a request, the provider issues a token limited to the approved scopes, and the agent acts on that person's behalf. The [Google OAuth 2.0 documentation](https://developers.google.com/identity/protocols/oauth2) describes the pattern: consent, scopes, a short-lived access token and, in many cases, a longer-lived refresh token that lets the agent keep working until the grant is revoked.

The question that separates them is simple: whose action is this? If the action belongs to the company, such as posting to a shared channel or updating a job record, a service account fits. If the action belongs to a person, such as sending from their mailbox or reading their private calendar, OAuth fits, because the provider will enforce what that person can see.

There is a hybrid that deserves caution. Some providers let an administrator authorize a service account to impersonate users across the whole organization. That combines the standing, unattended nature of a service account with the reach of every user it can impersonate. Treat it as a high-risk grant that needs a named owner and a narrow list of permitted actions.

How do they compare on traceability?

Traceability has two layers: what the provider records and what your own agent records. The access model changes the first layer. It should never replace the second.

With a service account, the provider log shows the service account performing the action. That is useful: anyone reviewing it can tell the activity was automated. What it cannot show is which request triggered the action or which colleague asked for it. If five workflows share one account, the provider log cannot tell them apart.

With OAuth, the provider log usually shows the approving person as the actor. A mistaken edit by the agent then looks identical to a mistaken edit by that employee. Some providers also record the connected application, which helps, but you should not assume every system does.

So the working rule is that the agent keeps its own record, regardless of model. For each action, capture:

• The request or conversation that triggered it
• The person who asked, and the person who approved, if approval was required
• The tool called, with the inputs and the outcome
• The identity used, meaning which service account or which person's grant
• A reference you can search for in the provider's own log, such as a record identifier

With those fields, a reviewer can start from either side: from a strange entry in the provider's log back to the agent's reasoning, or from an agent decision forward to the change it made. Without them, a service account gives you a clear actor and no story, and OAuth gives you a story attached to the wrong name.

How do they compare on revocation?

Revocation is the question that matters most on a bad day. Both models can be cut off, but the consequences differ.

A service account gives you a single switch. Disable the account or rotate its credential and the access stops. The cost is breadth: if several workflows share the account, all of them stop together, and rotating a key means finding every place it is stored and replacing it. The remedy is design, not tooling. Give each integration its own service account, and keep test and live identities separate, so that revoking one never takes down unrelated work.

An OAuth grant is revoked per person and per application. The user can often do it themselves and an administrator can do it too. That is a strength for containment, because one person's grant can be removed without touching anyone else's. It is also a weakness for continuity. Tokens stop working when a person changes their password, leaves the company, loses a license or when an administrator tightens a policy. The agent then fails at a moment nobody planned for. The pattern for handling that gracefully is covered in what an AI agent should do when a connection expires.

The opposite failure is worse: a former employee's grant that nobody revoked and that keeps working. Departures should include a step that lists every agent connection tied to that person and either removes it or moves it to a company-owned identity. A fuller plan is in offboarding employees who used a company AI agent.

Whichever model you use, rehearse the cut-off. Revoke a test credential, watch what the agent does, and confirm that it stops, reports the failure and does not retry in a loop. A revocation you have never tried is an assumption, not a control.

How do they compare on scope?

Scope is where most incidents begin, because access is easy to grant and rarely reviewed.

A service account can be as narrow as you choose: one folder, one table, one queue, one project. The risk is drift. Because the account is shared and unattended, it is tempting to add one more permission when something fails, and nobody removes it later. After a year, the account can reach far more than the original task needed.

OAuth scopes are defined by the provider, and they are often coarser than the task. A scope that lets the agent read mail may allow it to read the entire mailbox when you only wanted messages with a particular label. On top of that, the effective reach equals the scope intersected with what the approving person can already access. A token granted by a senior manager reaches more than the same token granted by a new coordinator, even though the consent screen looks identical.

The [OWASP authorization guidance](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) points to the habits that apply here: deny by default, grant the least privilege needed, and check permissions on every request instead of once at setup. The [OWASP Top 10 for LLM Applications](https://genai.owasp.org/llm-top-10/) lists excessive agency as a risk in its own right, which is the agent version of the same idea. An agent that can do more than its job requires will eventually do more than you intended, whether through a mistake or through manipulated input.

In practice, separate reading from drafting from sending, and grant only the first until the agent has earned the others. The reasoning is laid out in least privilege for AI agents, and the specifics for mail and calendars in granting only what the agent needs in Google Workspace and Microsoft 365.

How do you choose per integration?

Treat the choice as a short decision for each system the agent touches. Start with these rules:

• Choose a service account when the work belongs to the company and should continue regardless of who is on leave, for example a shared support queue, a project board or a document store.
• Choose OAuth when the data is personal to one user and the provider should enforce that person's own permissions, for example a private calendar or an individual mailbox.
• Choose a service account when the provider offers fine-grained roles, so you can limit access to one resource instead of an entire account.
• Choose OAuth when the provider offers only coarse service roles but supports narrow user scopes, and make sure the approving user is someone whose own reach is limited.
• Avoid organization-wide impersonation unless no other path exists, and then document the owner, the permitted actions and the review date.
• Avoid personal logins entirely. Sharing a person's password with an agent removes both traceability and clean revocation.

Then apply the choice in order:

• List every system the agent will touch and the specific actions it needs in each.
• For each action, decide whether it belongs to the company or to a person.
• Pick the identity type, and create a separate identity per integration and per environment.
• Grant the smallest scope that supports the first version of the task, read-only where possible.
• Record the owner, the reason, the review date and the revocation steps next to the integration.
• Test the cut-off in a staging environment, then confirm the agent logs the failure and stops.
• Review the grants on a schedule and remove anything that has not been used.

What does this look like in practice?

This is an illustrative scenario, not a real case. A small property services company wants an agent to triage its shared support inbox, draft replies for a coordinator, update a job tracker and check the coordinator's calendar before proposing site visits.

The shared inbox and the job tracker belong to the company, so each gets its own service account. The inbox account can read and draft but not send. The tracker account can write to one project only. Neither can see anything else.

The coordinator's calendar is personal, so it uses OAuth with the narrowest calendar scope the provider offers, approved by the coordinator. When the coordinator goes on extended leave, the calendar grant is paused and the agent tells the operations lead that site-visit proposals need manual scheduling. The inbox and tracker work carries on unaffected, because they never depended on one person's login.

In the agent's own log, each draft and each tracker update records the triggering request, the identity used and a reference to the record. When someone asks why a job changed status, the answer takes minutes, not an afternoon of comparing timestamps.

How does Be Human handle access for agents?

In a first engagement, Be Human defines one role for the agent and then, for each integration that role needs, decides the access model, the scope, the owner and the approval boundary. Credentials are held in managed storage outside the agent's prompts and memory, and each integration and environment has its own identity so that one can be revoked without affecting the others. Managed operations include monitoring for expired or failing connections, permission reviews, integration maintenance and revocation tests, all under the client's control.

Frequently asked questions

Can an AI agent just use an employee's own login? It can technically, but it is the weakest option. The provider log cannot distinguish the person from the agent, the password has to be stored somewhere the agent can reach, and revoking the agent means changing the employee's credentials. Use a service account or a proper OAuth grant instead.

Is OAuth safer than a service account? Neither is safer by nature. OAuth ties access to a person and a consent record, and tokens are short-lived, which helps containment. A well-scoped service account with its own identity and a named owner can be easier to audit and less fragile. The safer choice is whichever one lets you grant the narrowest scope and revoke it cleanly for that integration.

What happens when an OAuth token expires or is revoked? The agent loses access to that system until someone reauthorizes it. A well-built agent stops the affected task, records the failure, tells a named person and does not retry endlessly or switch to another credential on its own. Plan who receives that alert before launch.

Should test and live environments share credentials? No. Use separate identities for each, with test credentials that can reach only test data. That way an experiment cannot change live records, and you can revoke one environment without interrupting the other.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.