The AI agent identity gap underneath every Black Hat 2026 conversation

There is a particular kind of clarity that emerges at a security conference when the whole industry works through the same structural problem at the same time, even if the people in the room have not yet agreed on what to call it. Black Hat 2026 was that kind of show, and the problem was AI agent identity.

Every serious conversation, whether on the floor, in meetings, or in the more honest sidebar exchanges, arrived at the same place. Security teams wanted to know which AI agents were operating inside their environments, what those agents could reach, which credentials they were using, how to apply least privilege to something that writes its own next step, and how to stop an agent whose behavior changed at machine speed.

These are the right questions. They sit atop a layer the industry hasn't yet named correctly: the assumption that the AI agent is the new identity. An AI agent isn't a stable principal like a person, service account, or workload. Its authority depends on the user, task, credentials, tools, context, and target systems. Having a name and an identifier doesn't mean it has a single security identity.

Black Hat surfaced a clear reality: the real security object is not the agent. It is the temporary delegation assembled around each execution. Almost nobody has a reliable way to govern it.

Why has AI agent security moved past prompt injection?

For two years, AI security was framed as a content problem. Could the model be jailbroken? Could an attacker manipulate the prompt? Those questions matter, but they describe systems where the primary output is text. An AI agent does not merely produce text. It takes action. It reads repositories, queries databases, opens tickets, changes configurations, calls APIs, invokes other agents, and executes workflows across multiple systems simultaneously. To do any of that, it needs real authority inside the enterprise.

That changes the threat model completely. A compromised chatbot might generate an unsafe response. A compromised agent can use valid credentials to perform a valid operation for an invalid reason.

Nothing about it looks like an intrusion. No malware, no stolen password, no impossible login. Every individual request can be technically authorized, yet the sequence of requests can produce an outcome nobody intended to authorize. Prompt security increasingly feels like inspecting the conversation while ignoring the transaction. The question is no longer whether an agent can be manipulated. It is what becomes possible afterward.

What are security teams actually asking about AI agents?

Underneath the different terminology, these conversations came back to three questions: discovery, access, and runtime control.

Discovery came first. How many AI agents are running, who created them, which systems contain embedded agents, which employees are running coding agents locally, and which agentic workflows arrived inside software the organization had already approved? Agents are not entering through one controlled program. Some are explicitly deployed, some are embedded within existing applications, some are assembled by developers, and others exist briefly as part of a larger workflow and vanish when the task completes.

Access came second. Which credentials are agents using? Are they receiving their own identities or inheriting a human user's permissions? Can their access be made just-in-time and short-lived, and how is least privilege supposed to work when the principal's next action is generated dynamically?

Runtime control came third. What happens when an agent begins doing something unexpected? Can security tell legitimate adaptation from compromised behavior? Can a single action be stopped without killing an entire business process, and can a decision be made quickly enough across thousands of parallel sessions?

These appear to be three separate problems. In practice, they fail for the same reason: the organization cannot reconstruct the authority under which a particular action is taking place.

Why is an AI agent not a single identity?

Traditional identity assumes a stable relationship between a principal and its permissions. A person joins a department, receives a role, authenticates, and does the work. A service account is created for an application, assigned an owner, and expected to behave within a consistent pattern.

AI agents break that. Picture the same coding agent used for three tasks: explaining an unfamiliar repository, fixing a vulnerability in a development branch, and investigating a production incident. Its registered identity does not change. Its legitimate authority should. Reading production logs might be reasonable in the third task and indefensible in the first. Modifying code may be necessary in the second and inappropriate while merely explaining the repository.

The named agent reveals little. Effective identity is assembled at runtime from the delegating human, the task purpose, the model, the credentials, the tools, the data, and the environment. Change any variable, and the security meaning changes with it. An agent inventory, therefore, gives an organization a reassuring count while overlooking the far larger population of delegations those agents create. The enterprise may have 500 identifiable agents and 50,000 materially different authorization contexts every day. The second number determines risk.

Why does dynamic least privilege fail for AI agents?

The popular answer is that least privilege must become dynamic. That is correct, but dangerously incomplete. Traditional least privilege is historical. If an identity hasn't used a permission, that permission is removed. That logic breaks for agents whose actions are task-dependent and unpredictable from past behavior.

The alternative is granting authority based on the agent's goal. This is circular. If the agent's reasoning is corrupted, the authorization system helps a compromised agent achieve its malicious objective.

A prompt-injected agent does not behave like a visibly compromised machine. It offers a plausible explanation for every action it requests, and that explanation comes from the same component whose integrity is in question.

An AI agent cannot be the authoritative source of its own intent. Intent has to originate outside the agent and arrive as a constraint the agent cannot rewrite.

Why is delegated authority the layer nobody governs?

A better model starts with delegation. A request creates a temporary authorization envelope describing what the agent may do. It must be more precise than a role and more enforceable than a prompt.

The envelope defines the permitted objective, the resources in scope, the tools the agent may invoke and the operations allowed through each, the data it may read or modify, the destinations information may travel to, the financial and operational limits, the conditions requiring human approval, the maximum duration, and the events that revoke the delegation immediately. The agent can reason and adapt inside that boundary. What it cannot do is widen the boundary by claiming a new action is necessary.

A prompt says, "Only access customer records required to resolve this case." An envelope says, "This execution may read these three fields from the customer record attached to ticket 4821, may not export them, may not contact an external destination, and expires in fifteen minutes." The first is advice offered to a probabilistic system. The second is a control.

The boundary has to sit outside the agent because agent failures are built out of ordinary operations. Reading a document is normal. Querying a customer record is normal. Calling an external service is normal. Generating a summary is normal. A sequence that combines all four might constitute exfiltration. Retrieving a ticket, opening a repository, editing a configuration, and triggering a deployment may each be permitted, and together they can carry an instruction hidden in untrusted content into production.

The dangerous property does not live in any single request. It emerges from the relationship between requests. So AI agent security cannot stop at authenticating each tool call. It has to evaluate the transaction being assembled over time: what information influenced the decision, which authority was used, what data entered, where the outputs traveled, and which earlier action made the current one dangerous. Without that chain, runtime monitoring produces logs without understanding.

What is the path forward for securing AI agents?

Adding human approval is sensible for consequential actions, but it isn't an architecture. At agent scale, constant approval creates alert fatigue. Reviewers approve out of habit without context. Human involvement belongs at explicit changes in consequence; routine enforcement must be mechanical.

The sequence that works starts with discovery, and it does not end at an agent inventory. Organizations need to identify the credentials, tools, connections, and delegation paths associated with those agents. An agent holding no direct credential can still act through a tool that carries broad authority, and a registered agent can spawn sub-agents whose actions are attributed only to the parent workflow.

Then separate agent authority from human authority. An agent acting for an employee should not inherit everything that employee can reach. Delegation should produce narrower, short-lived authority derived from the task rather than a copy of the user's session. From there, check every consequential action against the envelope at execution time. Authentication establishes which components are participating, authorization establishes whether this transaction is permitted, and runtime controls limit where it can execute and where its outputs can travel.

Finally, keep a delegation record rather than an activity log. For any important action, security should be able to reconstruct who initiated the task, what they authorized, which agent and model executed it, which credentials and tools were used, what context influenced the decision, what data crossed a boundary, why the action was permitted, whether the delegation changed mid-execution, and how the authority ended. Each step depends on the one before it. Without that chain, there is no agent accountability, only scattered telemetry.

What is the final takeaway?

Black Hat showed that the industry has moved past treating AI security as a prompt-filtering problem, and that shift was overdue. Agents hold credentials, invoke tools, make decisions, and create consequences. Identity belongs at the center of the conversation. But identity is not the end of it. The agent is too broad and too unstable to be the primary unit of authorization. The same agent can be safe in one task and catastrophically overprivileged in the next, and knowing its name, owner, entitlements, and history does not establish whether its current action is justified.

The organizations that deploy AI agents safely will govern delegation rather than catalog agents. They will bind authority to a specific task, principal, context, toolset, consequence, and time period. They will enforce those boundaries outside the agent's reasoning. And they will read sequences of actions as transactions rather than treating every valid API call as evidence of legitimate behavior.

The question that matters is no longer which agent this is and what it can access. It is who authorized this agent to perform this particular action, under these conditions, and whether that authority can be enforced without trusting the agent to explain itself.

The practitioners who left Black Hat 2026 with the clearest path forward were the ones who saw that discovery, access, and runtime control are expressions of the same challenge, and that the challenge starts and ends with delegation. Until an organization can answer that question at runtime, it has not secured its AI agents. It has only given autonomous software an identity.

‍