At 11:47 p.m., an AI coding agent reads a bug report, edits the code, installs a package, and opens a pull request. The team set it up with an engineer's token because that was the fastest path to a demo.
The agent did the work. The audit log says a person did it.
That is an identity failure, not a prompt problem.
Every agent that can take action has an identity, whether the IAM team created one or not. Borrowed credentials blur accountability. They may give a machine the same reach as the person who configured it.
An agent that can act needs its own name, limits, and audit trail.
We are past the stage where an agent only drafts a paragraph. Teams are connecting agents to source code, ticketing systems, cloud consoles, customer records, procurement, and payment workflows. A patient may never know an agent updated a record. A developer may not see a package installed in the background. A finance team may discover that an automated workflow changed a supplier's bank details.
OWASP's 2026 Top 10 for Agentic Applications names identity and privilege abuse among the risks security teams need to manage. On September 29, NIST's National Cybersecurity Center of Excellence said its first implementation use case will show how agents can be identified, authenticated, and authorized inside a secure software development lifecycle. That is a useful signal. Identity is becoming a core control for agent deployment, not a clean-up task for later.
Stop letting agents borrow human authority
If an agent uses a developer's login, the system has inherited a human identity without inheriting that person's judgment. The agent can act at machine speed, across several tools, while the logs point back to someone who may be asleep.
That weakens incident response. It also creates a bad choice when the person leaves, changes roles, or needs access revoked. Disable the person's account and disrupt their work. Keep it alive and leave the agent's access in place.
Neither answer is acceptable.
I want every production agent treated as a distinct nonhuman identity. Record who owns it, who authorized it, what task it serves, which tools it can call, and when its access expires. A shared API key in a configuration file is not an identity strategy.
Three controls before an agent gets real access
Give it a distinct identity. Use a dedicated workload identity or equivalent mechanism. Make the agent's actions distinguishable from a human's. When it acts for someone, preserve that relationship in the audit record.
Scope access to the task. A code review agent does not need production write access. An agent preparing a payment does not need authority to release it. Permissions should name the allowed resource and action, then expire when the work ends. Require a person to approve actions that move money, change access, publish externally, or alter production.
Make the action visible and reversible. Log the agent identity, authorizing person or service, permission grant, tool call, target, and result. Give the security team a way to stop the workflow and revoke its credentials without relying on the agent to cooperate.
An agent can chain authorized actions. A harmless read can inform a risky write. A message can carry instructions that look like authority. A token can travel further than planned.
Run the uncomfortable tabletop
Pick one agent already in use. Follow its chain from the hosting service to each tool, then to the final business action. Put a realistic failure on the screen: a poisoned ticket asks the coding agent to add a package and expose a secret in a test log. Ask who can see the activity, who can stop the run, and whose approval the agent is allowed to rely on.
Do not accept “the model should know better” as the control. Models change. Context changes. Permissions remain.
This is a CISO decision because it crosses identity, application security, cloud operations, and business ownership. The first agent does not need a six-month governance project. It needs an owner, a bounded identity, a narrow permission set, and a tested stop button.
AI agents need their own credentials because they are new actors in our systems.
This quarter, I am watching which organizations can name their agents, explain what each one is allowed to do, and reconstruct every consequential action. Fellow CISOs, are your agents using their own identities, or are they still borrowing yours?
Lekshmy Sankar, PhD