Passwords became a security problem because they could be separated from the people they were meant to authenticate. Once shared or stolen, the same secret could be reused until someone detected the misuse and revoked the credential. Enterprises have spent years moving away from that model toward access tied more closely to the identity and context of the person making the request.
AI agents are introducing the same weakness into automated workflows, but at machine speed and across multiple systems. A credential granted for one legitimate task can remain active after the work ends, the agent’s purpose changes, or the person who authorized it moves to another role.
Unlike a conventional application following predefined instructions, an agent may decide which tools to call and what steps to take. Lingering access can therefore be used in ways the person who authorized it never anticipated.
Consider an agent authorized to assemble a customer renewal proposal. It may need temporary access to a CRM platform, pricing files, email, and a contract system. If those connections rely on reusable tokens or a standing service account, the agent could retain access after the proposal is complete.
A malicious instruction embedded in a document, a compromised tool, or a later workflow could then cause the agent to retrieve or transmit information unrelated to the original assignment.
Static Secrets Do Not Belong in Autonomous Workflows
Reusable credentials are dangerous because they turn access into possession. Whoever or whatever holds the secret can use it until the credential expires, is rotated, or is revoked. That model is risky for human users. The consequences are greater when it is applied to agents that can call tools, interact with applications, and trigger workflows.
Teams often connect agents to existing credentials so the agents can perform business tasks. That shortcut makes the agent an independent holder of access rather than a temporary executor of a person’s instructions. It also combines two risks that enterprises have traditionally managed separately: the credential may be stolen, or the agent may use a valid credential to perform an unauthorized or unintended action.
Once that happens, the enterprise can lose the connection among the credential, the person who authorized its use, and the task for which it was granted. A conventional access log may show which token called an application programming interface and when. It may not show who instructed the agent, what objective the agent was pursuing, which intermediate decisions it made, or whether the resulting action remained within the original assignment.
What Human Authentication Can Teach Us
Modern passwordless authentication offers a useful lesson for agent security. Instead of asking users to present a reusable secret, it relies on cryptographic proof tied to an authenticator and evaluates the identity, device, and context surrounding the request. This makes credentials harder to steal, share, or replay.
Agent access should follow the same principle without treating agents exactly like human users. Rather than storing a long-lived secret, an agent should request access for a defined purpose, with each request evaluated against the person’s authority, the agent’s assigned task, and the risk of the proposed action.
Any access granted should cover only the required systems, data, and actions, and it should end when the task is completed or the underlying authority changes. Agents may need to act quickly, but speed does not require permanent possession of sensitive credentials.
Controlling Delegated Authority
The hardest part of agent access is not authenticating the agent. It is controlling what happens after a person delegates authority to it.
When a person directs an agent to act, the agent exercises delegated authority. Its permissions may come from that person’s role, policies governing the business process, or restrictions imposed by the target service. Each action must remain traceable to the person who initiated the task and the policies that permitted it.
That chain becomes more difficult to preserve when one agent invokes several tools, calls another agent, or continues working after the person who initiated the task is no longer present. Security teams must be able to determine not only who started the process, but also what that person approved and whether every subsequent action remained within those boundaries.
A token by itself does not preserve that chain of authority. It may identify a scope and expiration, but it does not necessarily establish who delegated the task, how that person was authenticated, what outcome was approved, or whether the person remained entitled to authorize it.
This is where identity verification and authentication become foundational to agent governance. The greater the risk of the action, the more confidence the enterprise needs in the identity and authority of the person delegating it. Routine activity may rely on existing authentication and policy, while sensitive workflows may require step-up verification or stronger proof of identity before an agent is allowed to act.
Brokered Access Has Limits
Credential abstraction gives security teams a practical way to keep reusable secrets out of agent workflows. Instead of placing an API key in an agent’s configuration or assigning the agent a standing service account, an organization stores the credential behind a broker or policy enforcement layer.
The agent must request access through that layer for each specific action. The broker evaluates policy, risk, and identity context before issuing a short-lived credential limited to that action. Short-lived does not automatically mean low-risk. A credential valid for only a few minutes may still permit a damaging payment, data transfer, or configuration change. Its scope must restrict what the agent can do, not merely how long it can remain connected.
Higher-risk requests can trigger additional approval or stronger identity verification. In legacy environments, the broker may retain a long-lived credential while preventing the agent from accessing it directly.
Limiting access by system, data, action, and duration reduces the potential blast radius and creates a clearer audit trail. Each action can then be traced to the person who initiated the task, the authority delegated to the agent, and the policy under which it was approved.
These protections break down, however, if an agent can reach the target system directly or pass work to another agent outside the enforcement path. Endpoint and network controls must block those routes, while audit records preserve the connection among the original request, the authority behind it, and the resulting action.
What Security Teams Should Do Now
Organizations should begin by identifying which agents can access business systems, what credentials they use, and who authorized those connections. Credentials embedded in agent configurations or attached to standing service accounts deserve particular scrutiny.
Security teams should restrict access by system, data, action, and duration. Sensitive activity may require stronger authentication or explicit approval, while endpoint and network controls should prevent agents from bypassing the brokered access path.
Agent access should also be reviewed when employees change roles, workflows are modified, tools are added, or agents begin delegating work to other agents. Those changes can expand the practical reach of an existing credential even when its documented permissions remain the same.
Preventing Another Generation of Passwords
AI agents can accelerate credential sprawl and magnify its business impact. If teams connect agents by copying keys into configurations or attaching them to standing service accounts, security teams lose control over where privileges reside, how they are used, and when they should be revoked.
A better approach keeps privileged credentials out of agents’ hands and grants permissions only for the task at hand. Policy ties that authority to a verified source and terminates the agent’s access when the work is complete or the basis for granting it changes.
Organizations can then use agents without allowing task-specific access to become a permanent entitlement—and another version of the password problem they spent years trying to solve.
