Ana has access to the ERP. An agent is created to help her and starts running some tasks with her credentials. Weeks later a relevant change shows up in a record, and the log shows a single line.
Ana changed the data.
The line is true and answers nothing. Did Ana make the change herself? Did she ask the agent? Did the agent change it as a step inside another task? Did some process trigger the agent without her watching? When a person and an agent appear in the system as the same identity, the company loses the ability to reconstruct the chain, and loses with it the ability to treat the two differently.
Autonomy, permission and identity answer different questions
It is worth separating three questions that usually arrive bundled into one.
Autonomy asks how much the agent decides and executes without new approval. Permission asks which data, tools and systems it can reach. The relationship between those two was covered in how much autonomy to give an AI agent. Identity asks something else: who the system recognizes as the author at the moment the action happens.
The third does not derive from the other two. An agent can have minimal autonomy and still need its own identity. Consider an agent that executes a payment already approved by a person. It did not choose the supplier, did not set the amount and did not decide whether the company should pay. But it was the one that entered the system and executed the step. In that case the company needs to preserve two facts, not one: who authorized and who executed.
The log has to hold two roles, not one
For a long time the identity attached to an action was treated as a direct stand-in for whoever performed it. With agents, that association breaks. A person asks, the agent executes, a policy allows, another system receives. Each part plays a distinct role, and compressing all of it into one credential erases the difference.
The private preview of Agent Identity in watsonx Orchestrate, announced by IBM in September 2026, describes the separation in two useful terms. Execution records the subject, the user on whose behalf the action is taken, and the actor, the agent that carried it out. They are different fields, filled by different entities, and one does not substitute for the other.
This does not settle accountability. Agent identity does not decide who answers for a decision and does not remove human responsibility. Its job is more modest and more basic: to preserve evidence of who actually executed. Without that evidence, discussing responsibility afterwards becomes an exercise in reconstructing memory.
A service account does not cover what an agent does
The reasonable objection shows up fast. Companies have been creating identities for software for decades, with service accounts, certificates and tokens. Why talk about agent identity as if it were a new category?
Because an agent behaves differently from a traditional workload on four counts. An application usually has a stable function, while an agent receives a goal and decides which tools to use to reach it. An application runs continuously, while an agent may exist for minutes. An application serves one system, while an agent may work on behalf of different users across a single day. An application is provisioned, while an agent can be created and terminated dynamically, by the thousand.
IBM points at the limitation right where the problem starts. Shared service accounts, static API keys and reusing a user's credentials no longer distinguish what the person did from what the agent did on their behalf.
None of that makes service accounts obsolete, and none of it forces a company to buy a new product category. The rule is simpler. When actions have to be attributed and controlled separately, the actor has to be identifiable separately.
A name in a catalog is not an operational identity
There is a confusion that is easy to make and expensive to discover. A company builds an inventory with dozens of agents. Finance Agent. Sales Agent. HR Agent. The inventory is useful, and it proves only that the company knows they exist.
Operational identity is a different thing, measured by four capabilities at the moment of the call. The system receiving the request can verify which agent is calling. Policy can be applied to that specific agent. The log can preserve who executed. And the company can withdraw that agent's authority.
Without those four, what exists is administrative identification. The agent has a name in a spreadsheet and stays anonymous exactly where it matters, which is the instant it touches a production system.
Revoking the agent should not require revoking the person
The coupling between the two identities charges its price at the worst moment. If the agent operates with Ana's credential and something goes wrong, stopping the agent means taking down her access. The company chooses between containing the problem and halting a person who did nothing.
Separate identity removes that choice. The person keeps her access, the agent loses its authority, and the two decisions become independent.
Microsoft published a direct formulation of this in October 2026, stating that every agent should have a first-class identity distinct from the person using or sponsoring it. Alongside it came a mechanism called Dynamic Permissions, whose premise is that the agent does not automatically inherit the user's standing access. It starts with no authority and receives only what the approved task requires, for a defined period, with that authority reduced or removed when the task changes or ends. Separating identity from permission is what allows the limit to be applied to the correct actor.
The payment case shows the design working
In October 2026, Visa, BILL and Billtrust put a live pilot into production for agents completing payments on already-approved invoices. The agent does not decide whether the debt should be paid, because the approval already exists. Its role is to execute the next step.
The design matters more than the product. The agent is registered in the Trusted Agent Protocol and in Visa's agent directory, uses tokenized payment credentials instead of a shared supplier-portal login, and the supplier side recognizes and authenticates the authorized agent without requiring it to pass through a human login. That authentication can even replace protections such as CAPTCHA, which exist precisely to stop whatever is not a person.
The chain stays whole and readable. The person authorizes, the agent is identified, the system authenticates the agent, policy limits what it can do and the action is attributed to the correct executor. It is the opposite of handing someone's login to an agent and treating everything that follows as if the person had done it.
Banks hit the same problem from the opposite side
Two days after the pilot came the opposite signal. Reporting from October 22, 2026 described large US banks restricting third-party agents trying to reach customer accounts, in cases that included customers sharing their own login credentials with the agent.
The sourcing calls for care. It rests substantially on anonymous sources and relays another outlet's reporting, and one of the institutions named publicly stated it had not observed unauthorized agents on its platforms. What holds the point up is not the count of banks, it is the reason for the restriction.
The two movements look contradictory and share one root. On one side, a path where the agent is recognized before acting. On the other, blocking an agent that shows up wearing a person's credential. The question is identical in both. Can the system tell who is coming in, on whose behalf and with what authority?
A recognized, authorized agent is a policy problem. An agent indistinguishable from a customer is an identification problem, and no policy resolves what the system cannot see.
Five questions before giving an agent real access
Who the system recognizes when the agent acts. If the answer is a person's name or a shared generic account, there is an attribution gap.
The agent's action is distinguishable from the human one. That difference has to show up in logs and integrations, not only in internal documentation.
The agent's access is revocable without removing the person's access. If it is not, the two identities are still coupled and containment is expensive.
The system authenticates the agent at the moment of the action. Existing in an internal catalog is not enough. The identity has to be verifiable when it interacts with another system.
The log preserves who authorized and who executed. Separate identity does not remove delegation, it allows both sides of it to be recorded.
These are security and architecture questions at once. Organizations that already treat identity and least privilege as installed capability answer four of them without a new project, because the vocabulary is the same and only the actor changes.
The company's next identity problem may not be human
Corporate identity was built around people, applications and machines. The agent occupies a space that is none of the three. It acts on behalf of a person without being that person, reaches systems without working like a traditional application, may exist for one task and disappear, may receive temporary authority, and produces actions that have to be attributed to it.
None of that forces anyone to redesign their identity architecture tomorrow. The groundwork for treating the agent as a governed actor was covered in autonomous agents and what is missing to scale. What changes now is that a previously unnecessary question has become operational.
When an agent acts in your systems, will they be able to tell that it was the agent? Because a company only investigates, limits and revokes with precision what it can identify.
Sources
- Microsoft. "Agents are your newest insiders. Security must move at their speed" (October 19, 2026). https://www.microsoft.com/en-us/security/blog/2026/10/19/agents-are-your-newest-insiders-security-must-move-at-their-speed/
- IBM. "Announcing the private preview of Agent Identity in IBM watsonx Orchestrate" (September 21, 2026). https://www.ibm.com/new/announcements/announcing-the-private-preview-of-agent-identity-in-ibm-watsonx-orchestrate
- Visa. "Visa, BILL and Billtrust Launch First Live Pilot for Trusted AI Agent Payments Between Buyer and Supplier Platforms" (October 20, 2026). https://usa.visa.com/about-visa/newsroom/press-releases.releaseId.22856.html
- Reuters. "US banks are blocking third-party AI agents access to customer accounts, sources say" (October 22, 2026). https://www.reuters.com/legal/government/us-banks-detect-unauthorized-ai-agents-customer-accounts-axios-reports-2026-1022/
Note: the reporting on US banks rests on anonymous sources and relays another outlet's work. One of the institutions named publicly stated it had not observed unauthorized agents on its platforms, which is why this text addresses the reason for the restriction rather than the count of institutions. The subject and actor split is IBM's nomenclature. Dynamic Permissions, the Trusted Agent Protocol and the agent directory are mechanisms named by their respective vendors, with no correspondence to an open standard.
