Service Account Management for AI Agents at Scale
Non-human identities now vastly outnumber people in many environments, and that changes the job entirely. Google Cloud's service-account guidance uses 90 days without authentication as a warning signal and 180 days as the dormant threshold, which tells you the problem isn't creation, it's continuous ownership, review, and retirement of machine identities that never stop existing. In practice, service account management stops being a tidy IAM task and becomes a lifecycle problem for browsers, inboxes, credentials, TOTP flows, approvals, and audit history.
Table of Contents
- Why Service Account Management Fails for AI Agents
- Provisioning Durable Agent Identities
- Securing Credentials and Authentication Flows
- Traditional IAM Versus Agent Identity Infrastructure
- Auditing and Offboarding Agent Accounts
- Building Your Agent Identity Framework
Why Service Account Management Fails for AI Agents
Traditional service account governance was built for systems an organization controls. AI agents are different, because they keep running into third-party sites that want email verification, browser persistence, MFA, and long-lived account ownership, not just an API token and a clean IAM policy.
The scale issue is already bad enough on its own. A 2026 industry analysis citing CyberArk's 2025 Identity Security report cited about 82 machine identities for every human identity, and 42% of those machine identities carried privileged access, which is a strong signal that service account management has become a core control point, not a back-office cleanup task (oversight.gov PDF). A separate U.S. Postal Service OIG audit found 25 privileged accounts without proper authorization out of 186 reviewed across 159 systems, or about 13.4% of the sample, which is the kind of governance gap that shows up when ownership and review are treated as paperwork instead of operating discipline (oversight.gov PDF).
Practical rule: if no one can name the owner, the lifecycle state, and the next review date, the account already escaped governance.
Why the usual IAM model breaks
NIST's National Cybersecurity Center of Excellence defines privileged account management as the IAM domain focused on monitoring and controlling administrative accounts, which is a good fit for infrastructure you own, but not a complete model for third-party accounts that agents must keep alive (IT Perfection reference). The gap shows up fast. An agent can't just “assume role” into a SaaS portal that expects browser cookies, TOTP, or a verification email.
Static credential rotation helps, but only when the identity itself is disposable. Google Cloud guidance recommends temporary, narrowly scoped authentication where possible, and warns against letting users create or upload keys because leaked or reused static keys persist until they're explicitly rotated or revoked (Securden educational guide). That's a good control for cloud automation. It doesn't solve the harder problem of an agent that must sign in again next week with the same browser profile and the same account state.
Provisioning Durable Agent Identities
Durable agent identities work best when provisioning is treated like workspace creation, not just credential issuance. Each agent needs a bounded identity surface, a place to receive mail, a browser profile that survives restarts, and a clear owner who can answer for it later.
Start with isolation, not convenience
The cleanest pattern is to give each agent, or each customer in a multi-tenant deployment, its own inbox, browser profile, and credential store. That keeps verification mail, password resets, and login state from bleeding across unrelated runs. It also makes it possible to prove which workspace did what without guessing later.
If you're provisioning at scale, bind the identity to an explicit owner and a lifecycle state on day one. “Provisioned,” “active,” “paused,” and “retiring” are more useful than vague labels like “temporary” or “shared.” Once the app team that created the account is gone, that metadata is what keeps the account from becoming folklore.
A good provisioning workflow also keeps secrets out of the model layer. Generate credentials server-side when you can, store them encrypted, and only type them into the live browser when the target origin matches. That origin check matters because a credential that can be filled anywhere eventually gets filled somewhere wrong.
Make onboarding survive the ugly parts
Signup flows fail in boring ways. Email verification times out, MFA enrollment gets interrupted, and a browser session dies halfway through. Persistent workspaces absorb those failures because the inbox, browser state, and credential history survive the process restart.
Agentstead fits that model by combining a durable workspace, persistent browser identity, email, credentials, TOTP authenticators, approvals, and activity history into one external identity primitive. For background on the identity lifecycle model, see Agentstead's identity guide.
The true test of provisioning is whether an agent can sign up once, return later, and still look like the same account holder to the target site. If you can't do that without exposing plaintext secrets to the model, the design isn't durable yet.
Securing Credentials and Authentication Flows
Credentials for agents need tighter boundaries than normal application secrets because the browser itself is part of the trust path. If the agent can read the secret directly, copy it into logs, or reuse it against the wrong site, you don't have credential management, you have credential exposure with extra steps.
Keep secrets on the server side
The safest pattern is origin-scoped credential fill. The browser should verify the live domain before a password gets entered, and the credential should never be returned through a read API. That avoids the common failure mode where a model or operator requests a secret for “debugging” and the secret never leaves the text layer again.
For TOTP, don't hand the seed or generated code to the agent. RFC 6238 sets the default time-step at 30 seconds, which is a concrete operational constraint for authentication flows that need to move quickly without leaking the authenticator secret (RFC 6238). Server-side TOTP computation keeps the seed encrypted and the resulting code transient.
Persistent browser profiles matter for the same reason. Microsoft Entra distinguishes persistent cookies from session cookies, and that distinction is exactly why browser state has to survive across runs if you want an agent to return to the same authenticated account later (Microsoft Entra browser cookies). A workflow engine can replay tasks. It can't fake a logged-in browser profile.
Don't treat refresh tokens like static passwords. Treat them like a chain of custody problem.
Rotate without breaking the session
OAuth refresh-token rotation is single-use by design. One source describes the old refresh token as invalidated when a new one is issued, and reuse detection should treat the superseded token as replay, revoke the token chain, and append a security audit event (Scalekit audit trail article). Salesforce's guidance is similar in spirit, because it says the client should overwrite the old refresh token in secure storage with the newly issued one and log refresh-token errors before starting a fresh auth flow (Salesforce help).
That pattern works because it separates long-lived identity from long-lived secret. The account persists, the session renews, and the old credential stops being reusable as soon as the new one is issued. For agents, that's the difference between a stable browser identity and a stale token sitting around until someone notices.
For browser sessions, use temporary elevation when possible and reserve standing privilege for the minimum set of actions that need it. If the agent has to log in through a human approval gate before a sensitive change, make that approval part of the workspace history so the later audit trail shows who permitted what and when. For browser-session specifics, see Agentstead's browser session guide.
Traditional IAM Versus Agent Identity Infrastructure
Traditional IAM is still the right answer when the target is infrastructure your organization owns. It handles cloud roles, server access, and internal service accounts well enough because the trust boundary is inside your control plane. The trouble starts when the account lives on a third-party site that expects a user-like identity with durable browser state.
| Capability | Traditional IAM | Agent Identity Infrastructure |
|---|---|---|
| Primary target | Organization-owned infrastructure | Third-party accounts and portals |
| Credential model | Roles, service principals, short-lived tokens, managed identities | Persistent workspace credentials, browser state, inboxes, TOTP authenticators |
| Session persistence | Usually external to IAM | Built into the workspace |
| MFA handling | Great for workforce and infrastructure flows | Needs browser-aware, origin-scoped handling for agent logins |
| Ownership model | Service owner, platform team, or cloud project | Explicit workspace owner plus lifecycle state |
| Audit trail | Cloud or IdP logs | Append-only account, browser, credential, and approval history |
| Multi-tenancy | Often account- or project-based | Isolated workspaces per customer, tenant, or agent |
| Failure mode | Excess privilege inside owned systems | Orphaned accounts and leaked secrets on third-party systems |
Traditional IAM succeeds when the only question is “can this workload reach that resource?” Agent identity infrastructure answers a different question, “can this agent keep owning the same external account safely across runs?” That includes email recovery, browser persistence, and account maintenance after the original setup run is long gone.
Where each model belongs
Use managed identities, service principals, or short-lived tokens when the workload talks to your own APIs, your own cloud, or systems with clean delegated auth. Use durable workspaces when the agent has to live inside a site that doesn't give you that path, or when login state itself is part of the product surface.
The practical distinction is simple. IAM handles authorization to infrastructure. Durable agent identity handles account ownership on someone else's infrastructure.
Auditing and Offboarding Agent Accounts
Auditing agent accounts starts with a simple question, does this identity still have a real job? If you cannot show why it exists, who owns it, and what it touched most recently, it is already sliding toward orphaned privilege.
Build logs that help security without leaking secrets
Append-only activity history is the right base. Record workspace creation, browser events, credential changes, authenticator enrollment, email verification, and approvals, but never store the secret values themselves. Security teams get a usable trail, and you avoid turning logs into a second secret store.
A separate approval gate belongs on sensitive actions, especially when the agent is about to do something that cannot be rolled back, such as changing payment details or exporting data. The goal is not to slow every run. It is to make risky actions explicit and reviewable instead of burying them in the normal loop.
Offboard the way you'd decommission production access
Dormant service accounts are a real governance signal. Cloud guidance also flags accounts with no authentication in a recent review window and accounts that have stayed inactive for longer periods. Those thresholds are useful for machine identities that should still be alive, but they matter even more when an agent's original workflow is gone and nobody remembers who owns the account. See the Google Cloud service-account guidance via the verified reference.
Practical rule: offboarding starts with ownership, not deletion.
When you retire an agent account, revoke superseded refresh tokens, remove stored secrets, and verify that the browser profile can no longer reauthenticate. Log refresh-token errors before you trigger a new auth flow, because that gives you a clean trail for the last successful credential state. If you have one account per workflow, you can delete with confidence. If you have shared accounts, you are usually untangling production debt. Agentstead can help keep that account history together, but the discipline still has to be in the offboarding process itself.
Building Your Agent Identity Framework
The right framework is boring on purpose. Separate the identity that the agent uses from the workflow that orchestrates it, then decide which system owns which piece. Orchestration can resume tasks. It can't replace browser state, TOTP enrollment, or the account history needed to keep a third-party identity alive.
Start with this decision checklist. If the workload only needs cloud access inside your boundary, use IAM primitives. If it needs external account ownership, persistent browser state, email verification, or human approval, move it into a durable workspace. If secrets must never reach the model, keep them server-side and origin-scoped. If multiple customers or agents are involved, isolate every inbox, browser profile, and credential store.
The main failure modes are predictable. Shared identities create blast radius. Static keys create stale access. Spreadsheet ownership creates orphaned accounts. And any design that makes the agent ask for plaintext credentials at runtime is already too loose.
Agentstead is one way to combine those primitives into a durable external identity for AI agents, with a workspace that keeps inboxes, browser state, credentials, TOTP authenticators, approvals, and activity history together. If you're building agents that need to create accounts, sign back in later, and keep operating on third-party sites, use Agentstead as the place to anchor that identity instead of improvising it in application code.
If you're building production agents that need durable browser identities, mailbox-backed verification, and server-side credential handling, start by mapping one real account lifecycle from signup to offboarding. Then use Agentstead to put that lifecycle into a persistent workspace your agents can return to safely.