Your AI Agent Is a Service Account That Can Improvise

An AI agent with production credentials is an identity problem before it is a model problem.

The model gets the attention. The credential decides the blast radius.

Once an agent can call an API, assume a cloud role, query a database, push an image, or open a pull request, IAM already has a category for it: non-human identity. Calling it an assistant does not change what appears in the audit log. A credential was presented, a policy was evaluated, and something happened.

There is one difference that makes the usual service-account playbook incomplete. A service account runs a job somebody described in advance. An agent can decide how to perform the job while it is performing it.

That is the useful definition: an AI agent is a service account that can improvise.

Same credentials, different actor

Nothing under the agent is especially new. It still uses API keys, OAuth grants, database passwords, IAM roles, CI credentials, and Kubernetes service accounts. Platform teams already know how to issue those identities, rotate their secrets, restrict their policies, and revoke them.

Those controls remain necessary. OIDC federation is better than distributing a static key. In Kubernetes, the safer baseline is already familiar: federate the workload to the cloud identity instead of placing a long-lived credential in the cluster. A token with a five-minute lifetime is less useful to an attacker than one copied into a configuration file two years ago.

AI does not make IAM obsolete. It makes sloppy IAM more expensive.

A conventional service account is usually attached to a known binary, workload, and call pattern. It may have excessive privileges or a forgotten owner, but its intended behavior is inspectable. The backup job does not decide that the fastest way to complete a backup is to create another identity and delegate half the work to it.

An agent receives a goal and constructs a path. It can read a ticket, inspect logs, search documentation, choose a tool, call another system, evaluate the response, and choose again. That flexibility is why teams want it. It is also why a role designed around a static call graph does not describe the risk very well.

Initiative changes the threat model

An agent plans at runtime. The privileged calls are generated from the current goal and context, not fixed in code somebody reviewed last week.

It also consumes untrusted input. An issue, email, web page, PDF, log line, or output from another agent can influence the next action. Instructions and data arrive through the same context window. If untrusted text changes the plan, the credential attached to the agent still works exactly as issued.

Tool chains make this worse. One request may read from a monitoring system, fetch a secret, modify a repository, trigger CI, and notify a chat channel. Reviewing each tool in isolation misses the path across them. The practical blast radius is the set of systems reachable by the chain, including the state left behind for the next call.

Delegation adds another break in attribution. A human authorizes one agent, that agent hands work to another, and the final mutation occurs several hops from the original approval. The audit trail may show which token called the API without showing why that token was there.

An earlier distinction still holds: a chatbot returns text while an agent changes state. The model can improvise. The credential cannot. It grants the same authority whether the plan is sound, mistaken, or manipulated.

Most teams cannot name the agents they already run

The available numbers are mostly vendor research and sponsored surveys. They are useful as warning lights, not as a census.

In April 2026, the Cloud Security Alliance published an online survey of 418 IT and security professionals. Token Security commissioned and financed the work and helped develop the questionnaire, which matters when weighing the result. In that survey, 82% of respondents said they had discovered previously unknown AI agents in their environment during the prior year. Yet 68% reported high confidence in their visibility.

The conflict between those answers is more interesting than either percentage. An organization can feel confident about the identities it manages while agents are appearing outside the process used to manage them.

The lifecycle numbers were worse. A formal agent-decommissioning process appeared in 21% of responses. Automatic blocking for an out-of-scope action was reported by 11%. Service-account debt grew for years because creation was easy and deletion belonged to nobody. Agents repeat that mistake with a lower cost of creation and a much wider choice of integrations.

A July 2026 1Password survey of 1,000 US employees found a similar gap. This was vendor research, split evenly between IT/security and developer respondents at companies with at least 250 employees. A highly secure path was available to 33% of the developers surveyed. At the same time, 65% said their organizations expected or encouraged agent use.

Forty percent of developers reported giving agents persistent access to systems or credentials. Across the full sample, 41% said agents were reaching data that had not been approved, and 71% reported gaps in knowing which agents were using which credentials. The responses are not verified incident records. They do show adoption moving through organizations faster than inventory, ownership, and revocation.

Attackers are using the same gap from the other direction. Sophos, citing its own threat-response work, reported a campaign it tracks as STAC6994 in which roughly 12 agents produced nearly 80 attack modules and more than 70 evasion techniques in days. The company’s 2026 ransomware dataset also put identity at the top of the initial-access list, something Sophos says had not happened for over three years.

These are Sophos findings, not neutral market measurements. The useful part is the mechanism. Attackers did not need a new door for AI. OAuth grants, developer credentials, exposed services, and weakly governed non-human identities were already there. Agents increased the rate at which someone could try the handles.

A vault is the starting line

Putting agent credentials in a secrets manager is basic hygiene. It removes literals from source code, centralizes rotation, and gives the platform a place to record retrieval. Do that first.

Then keep going, because a vault cannot answer why an agent is requesting a credential.

It can decide whether an identity may retrieve a secret. It does not know whether the current task requires that secret, whether the agent read an instruction from an untrusted page, whether the human approved a write, or whether the access should survive after the run finishes. A successful checkout with no task binding and no expiry tied to the work is evidence that access occurred. It is not proof that the access was appropriate.

The same separation applies to tool permissions. Better context and more authority are independent decisions. Giving an agent permission to inspect Terraform state does not imply permission to apply a plan. Letting it read an incident should not automatically let it close the incident, rotate credentials, and restart production.

Secrets storage protects material. Authorization has to constrain intent, scope, and time.

Bind the identity to the task

Microsoft describes agents as an emerging kind of non-human identity that may be created on demand, cross domains, switch roles, and use context-based credentials. The Cloud Security Alliance’s agent identity governance work reaches the same architectural problem from a broader angle: static identities already suffered from weak ownership, privilege creep, and poor decommissioning. Runtime delegation and changing permissions add more ways to lose track of them.

The control model I would use has four parts.

Purpose is the task the identity exists to perform and the person or team accountable for it. “AI automation” is not a purpose. “Open a ticket for this alert and attach the related log window, owned by the payments on-call rotation” is specific enough to review. If nobody owns the purpose, the identity is orphaned on the day it is created.

Scope covers systems, tools, data classes, actions, and network destinations. Reads and mutations should be separate grants. The agent may need broad context to investigate a problem and very narrow authority to change it. Egress restrictions and action-rate limits belong next to IAM here: they keep a bad plan from turning into an unrestricted loop.

Duration ties authority to the work. Prefer workload identity, managed identity, OIDC federation, and short-lived issuance over static credentials. The token should expire when the task does. A developer’s ambient OAuth session, a shared team key, or a standing administrator role has no task boundary for the policy engine to enforce.

Attribution connects the final action to the agent run, initiating human, credential, tool, approval point, and resulting state change. Logging only the token is not enough. Keep this evidence outside the agent’s write authority; an actor that can revise its own audit record is not meaningfully audited.

The production gate should be boring

I would reject production data access or a mutation API until the agent has all six of these:

• A unique identity for the agent or task boundary, not a borrowed human credential.
• A named owner who can explain why it exists.
• Credentials restricted to the systems and actions required for that task.
• Automatic expiry, with no manual cleanup needed for the normal path.
• An independent audit trail queryable by run and initiating user.
• A revocation procedure that has been tested and works without the agent’s cooperation.

The revocation test is not paperwork. Disable the identity and verify that the next call fails. Remove the agent and confirm every associated grant is gone. A documented kill switch that nobody has pulled is still a hypothesis.

Human approval also needs a boundary. Prompting for confirmation on every read creates fatigue and teaches operators to approve prompts without inspecting them. Blanket approval when the agent starts is the opposite failure: it authorizes actions that have not been planned yet. Put the gate at a sensitive mutation or a crossing between trust domains. The useful pattern is close to the one discussed for AWS DevOps Agent: investigate first, require a person before execution.

Teams keep asking whether the model is safe enough. That question matters, but it does not replace the IAM review. Model controls try to influence what the agent chooses. Identity controls limit which choices can change the environment.

Agents stop being toys when they gain tools. At that point, ask the questions that already work during an access review: Which identity is being used? Who owns it? What can it reach? Why does this task need that authority? When does the credential expire? How is it revoked?

If nobody can answer when the credential dies, the agent is not under control. It is just logged in.