Why AI agents need identity at runtime

An AI agent with permission to open GitHub may also have enough permission to force-push to a production branch at 2 a.m. That gap changes the security question for enterprises deploying agents. Knowing which systems an agent may access establishes one boundary, while safe execution requires deciding whether that agent may perform a specific action on a specific resource at a specific moment. Securing agents therefore requires verifiable identity as the runtime basis for those decisions.

AI agents expose the limit of application-level access control

That runtime requirement grows as enterprises add AI agents, applications, workloads, and other machine identities faster than employees. Many enterprises are planning for non-human populations several times larger than their human populations. As those populations grow, identity architecture constrains safe deployment because every production agent needs a verifiable identity, a credential resistant to leakage, and narrowly scoped permissions.

Those requirements expose a mismatch with enterprise identity and access management (IAM), the systems used to establish identities and govern their permissions. Current IAM platforms were built mainly around human identities and were not designed to issue this combination of identity, credentials, and permissions to software entities. Security leaders working on their first serious agentic-AI deployments consistently take the problem to IAM teams rather than endpoint or application owners. Their immediate work is to discover which agents exist, establish verifiable identities for them, and restrict what they can do to core systems.

Those restrictions matter once an agent starts working. Conventional IAM can determine whether the agent is entitled to enter an application or reach a resource. Runtime identity has to support a narrower decision: whether this identity may perform this action on this resource during this time window. Application access remains part of that decision, but actions within the application need their own authorization boundary.

Conventional IAM and zero trust are too coarse for agents

The need for a narrower boundary starts with assumptions built into traditional IAM. A human proves an identity through mechanisms such as a password, fingerprint, or face scan, then receives permissions according to a role broad enough to represent a job function. Admin, user, and read-only are familiar examples. Identity teams introducing agents therefore have to establish machine-specific identities, credentials, and permissions before those agents can operate under comparable governance.

Traditional least privilege already narrows access by matching resources to work responsibilities. An engineering employee might receive GitHub and cloud-console access, while a finance employee receives access to the accounting system. Those boundaries remain useful, but an agent operating through a human’s existing permission set can inherit a much wider field of possible actions than its immediate task requires. For an agent, the consequential authorization decision can sit inside the application.

Email makes that distinction concrete. Giving an agent email access for a legitimate task can also leave it able to move messages or send email to the board of directors. Matt Caulfield, VP of product, identity, at Cisco, describes the required credential and permission model this way: “We need to issue a credential, and it’s usually cryptographic, tied to hardware so nobody can steal it. Then we get to permissions. Saying an agent can access email leaves it free to move mail around or email the board of directors. Agents need just enough permission, just in time, for just long enough to complete the mission at hand.” Cisco has a commercial stake in this model because it sells Duo and other security offerings positioned to implement the identity controls Caulfield describes.

Caulfield’s permission principle narrows authorization along three dimensions: the capability required for the task, the time at which it is needed, and how long it remains valid. A standing entitlement creates a larger range of possible behavior than a task requires. Because agents can initiate actions without a person making each individual request, narrowing those dimensions changes authorization from a durable entitlement into a task-specific decision.

Zero-trust architecture encounters the same issue when its policy boundary remains at the level of users, devices, applications, and data sets. A policy can establish that a particular agent may connect to GitHub, for example, while the consequential question remains whether that agent may force-push to a production branch at 2 a.m. Once the connection is authorized, the action itself requires a separate decision.

Caulfield argues that this limitation calls for changing the unit being governed. “Zero trust was never really zero trust. It was trust in the identity systems,” he says. “We often say we need to evolve from access control to action control, and the only way to get there is to inspect every action, authorize it in real time before anything happens, and record all of it.” Under that model, identity establishes who or what is acting, while policy evaluates the requested operation before execution.

Existing least-privilege and zero-trust practices still provide useful constraints, but the email and GitHub cases show where action-level policy has to extend them. An agent can remain inside its approved application while performing an action the task never required. Agent security consequently needs authorization fine enough to govern operations within established application and resource boundaries.

Runtime identity changes the unit of authorization

Action control turns a persistent application-level entitlement into an ephemeral authorization for an individual operation. Each relevant action is inspected, evaluated against policy before execution, and recorded. Runtime identity supplies the verified actor behind that evaluation, letting policy bind an authorization to the entity requesting the operation and its current context.

A GitHub permission illustrates how narrow the resulting authorization can be. Caulfield describes an agent receiving five minutes in which it may merge one pull request without gaining the ability to read an entire repository or change other repositories. “This repository, this action, this window,” he says. Resource, operation, and time are therefore expressed together in a single authorization instead of being bundled into broad repository access.

That specificity also changes how authentication works during execution. One-time authentication has already been losing ground for human users, and an agent strengthens the case for continuing to verify context because its requested actions can change every few minutes. The proposed process starts by cryptographically binding the agent’s identity to a device, then establishing a secure channel to the system through which the agent operates. Identity becomes an input to subsequent authorization decisions throughout the session.

Operating that model at machine speed requires four linked capabilities: discovering agents already active in the environment; giving them hardware-bound cryptographic credentials; authorizing individual actions; and continuously recording their activity. Discovery establishes which software identities require governance, after which a credential gives each identity a verifiable basis. Action authorization then limits what that identity may do at a given moment, while recording preserves the history needed to establish what happened.

The identity problem continues when work passes from one entity to another. A request can move from a human to an agent, from that agent to another agent, and finally from the last agent to an application or data set. Each hand-off creates an enforcement relationship: human to agent, agent to agent, or agent to resource. Runtime governance therefore has to preserve enough trustworthy identity and context through each relationship to make the next action-level decision.

Preserving that context puts enforcement directly into the execution path. “Getting in line between agents and resources, agents and other agents, and humans and agents is the only way to inspect every action as it happens,” Caulfield says. “That position gives you continuous verification of the identity, continuous policy enforcement, and a full audit log of everything the agent did.” Cisco’s claimed benefits consequently depend on its security layer being present where the interaction occurs, before the governed action completes.

Runtime verification also addresses a difference between the processes used to establish trust in people and software. A company may spend weeks or months establishing confidence in a person before giving that employee access, whereas an agent can be created in minutes. Because the agent lacks that slower organizational process, the proposed architecture establishes and repeatedly verifies its identity while it operates.

Caulfield makes that difference explicit: “People build trust through a process. We know the same person, or the same company hired us, and that company ran a background check, ran an interview, verified our identity at onboarding. None of that exists for agents. We hire people over weeks or months. We hire agents in minutes.” His comparison shifts more of the trust-establishment burden for an agent onto verifiable identity and runtime enforcement.

Identity becomes infrastructure for the security stack

Once policy follows agents through execution, identity becomes a shared input across environments. An agent may run on a laptop, in the cloud, in a data center, or behind a third-party service, yet security controls still need a reliable way to determine which entity is producing an action. “That’s because whether agents are running on your laptop or in the cloud or in a data center, or behind third-party services, they all need identity,” Caulfield says. “That’s the only unifying principle across all of them. Identity is the one layer that reaches all of them.”

A common identity layer then gives other security controls an actor to govern. Network policy needs that actor before segmentation rules can make a meaningful decision, while threat detection needs it to connect behavior to an entity. Observability needs the same association to explain which agent produced an event. Identity, network, endpoint, and data security consequently meet where agent activity is attributed and governed.

That dependency broadens the work beyond an IAM redesign. “We need to almost rethink the past 30 years of security through the lens of agents,” Caulfield says. “How do we do identity security for agents? Network security, endpoint security, data security? Most enterprise security programs already have a strategy for each of those domains. They need another line underneath each one: how do we do that for agents?” Existing security domains therefore need agent-specific treatment because machine actors change how identity is established and how rapidly actions are taken.

Agent governance also requires closing human-credential bypasses

The shared identity layer depends on agents entering systems through identities that can be governed. A rollout built around runtime identity therefore starts with discovery because an unknown agent cannot be placed under policy. Core applications follow because a user able to mint an API key or personal access token can give an agent another route into a system. Employee authentication belongs in the same review because human credentials can also provide a route around machine-identity controls.

Passwords make that bypass especially direct. “If humans in your organization authenticate with passwords, people will hand those passwords to their agents,” Caulfield says. “The agent then acts as the person, and the two become indistinguishable. Phishing resistant authentication gives employees nothing they can share.” Once the same credential represents both parties, the identity system loses the distinction needed to apply agent-specific authorization and audit policy.

That loss of distinction means the human side of IAM directly affects agent governance even when an organization has designed strong machine identities. Passwords, API keys, and personal access tokens can collapse or bypass the separation if people can transfer them to software. The proposed human-authentication property is phishing resistance combined with credentials that remain bound to the employee or device, leaving the agent without a transferable human credential to reuse.

Cisco positions Duo as an implementation of this identity layer alongside its endpoint, network, and data-security offerings. For human identities, Duo uses credentials intended to remain bound to a user or device and continuously verifies identity and activity. Cisco says these controls reduce the chance that credentials will be passed accidentally to an agent or deliberately to an attacker. As the vendor of Duo, Cisco benefits commercially when enterprises adopt this approach to identity security.

For non-human identities, Cisco says Duo delegates narrowly scoped permissions through OAuth, the standard mechanism used to delegate access without handing over the underlying user credential. Duo also supports the authorization specifications used today by MCP, or Model Context Protocol, a protocol for connecting AI systems with external tools and data. It represents agents as first-class identities in its directory as well. Together, Cisco positions these mechanisms as ways to give an agent its own governable identity and delegate authority appropriate to a particular operation.

Discovery extends that model to software identities an enterprise may already have. Cisco says its acquisition of Astrix adds the ability to discover non-human identities and expose the accounts, permissions, and secrets those identities use. That discovery precedes action-level policy because teams first have to identify the identities and credentials through which existing agents can reach enterprise systems.

Inline enforcement becomes an execution-path dependency

Once teams have discovered those paths, action-level authorization requires the security layer to participate in them. Inspecting and approving actions before execution means the identity and security layer sits inline across the relevant connections among humans, agents, other agents, applications, and data. That position enables runtime enforcement because a policy decision can occur before the requested operation completes.

The same position also makes the enforcement layer part of the execution path for the work it governs. An architecture based on “inspect every action” consequently has to treat identity verification and policy evaluation as runtime infrastructure rather than a separate administrative process. The original GitHub case makes the dependency concrete: deciding whether an agent may force-push to a production branch at 2 a.m. is useful only when that decision can govern the action before GitHub executes it.

That requirement defines the implementation test for action-level authorization. The system has to preserve a trustworthy identity across human-to-agent, agent-to-agent, and agent-to-resource hand-offs, then apply the relevant policy when an operation is requested. For a legitimate merge, that can mean five minutes of authority over one pull request; for a force-push outside the permitted operation, the same identity and resource context lead to a different authorization decision.

Main highlights

• Govern AI agents at the action level: IAM teams need controls that decide whether a specific agent may perform a specific operation on a specific resource at a given time. Application-level access leaves too much authority inside systems such as GitHub and email.
• Make runtime identity the authorization foundation: Security teams can bind each agent to a verifiable, preferably hardware-backed identity and use that identity in real-time policy decisions. Task-specific permissions and short authorization windows reduce the scope of standing access.
• Preserve identity across every handoff: Agent workflows can move from humans to agents, between agents, and into applications or data. Security architects need trustworthy identity and context to follow those interactions so policy and audit records remain tied to the entity taking each action.
• Extend identity across the security stack: Network, endpoint, data, and threat controls all need a reliable way to attribute agent activity. Treating agent identity as shared infrastructure gives those systems a consistent basis for enforcement and observability.
• Close human-credential bypasses: Passwords, API keys, and personal access tokens can let agents operate as employees and undermine agent-specific controls. Identity teams can strengthen separation by adopting phishing-resistant human authentication, discovering non-human identities, and issuing agents their own credentials.
• Design inline enforcement as runtime infrastructure: Action-level authorization works only when policy is evaluated before the operation completes. Architecture teams need to account for the availability, latency, scalability, and audit requirements of an identity layer placed directly in critical execution paths.