Your Next Employee Doesn’t Have a Pulse: Key Takeaways from Dr. Chase Cunningham at HexCon26

TL;DR

• The moment an AI agent can take action, use credentials or work inside business systems, it starts to look a lot more like a digital employee than a simple tool.
• AI agents are already entering enterprise workflows, but visibility, ownership and governance are not always keeping up.
• Securing AI agent requires more than identity checks. Organizations also need controls around access, devices, sessions, browsers and runtime activity.

AI agents are becoming part of everyday work very quickly. They can log into systems, use credentials, complete tasks and act on behalf of employees. That is useful, but it also changes the security conversation. Because once an agent can actually do something, the question is no longer just, “Can we use AI?” It fans out into what it can access, what it’s allowed to do, and who becomes responsible when it acts?

That was the central idea behind Dr. Chase Cunningham’s HexCon26 session, where he explored what happens when AI agents start operating less like software and more like workers inside the enterprise.

His point was simple: an AI agent becomes an employee the moment it can take an action. And that makes securing AI agent a much bigger issue than just controlling which AI tools employees are allowed to use.

AI Agents are Already Here. The Controls aren’t.

The challenge is not getting companies to experiment with AI. That part is already happening. Employees are trying new tools, connecting services and finding faster ways to get work done. The harder part is keeping track of all of it. Dr. Cunningham repeatedly came back to the gap between what organizations are deploying and what they actually know how to govern.

That gap creates some very basic questions: Which AI agents are active right now? Who approved them? What systems can they access? Whose credentials are they using? And what happens when they are no longer needed? If an organization cannot answer these questions, it becomes very difficult to manage the risk.

This is also where Shadow AI enters the picture. Blocking every new AI tool is probably not realistic. But letting them spread without visibility is not much better. The more practical approach is to understand what is being used, which tools are approved, what data they can touch and where policy needs to step in.

When an AI Agent Can Act, Access Becomes the Real Question

Think about what happens when a new employee joins a company. They get an identity. Credentials. Permissions. Device controls. Access policies. Monitoring. And eventually, when they leave, that access gets removed.

AI agents do not always go through anything close to that process. A user might connect an agent to a business application, hand over an API token and let it get on with the task. If the agent needs more access later, that access may get added too.

Dr. Cunningham pointed out that once an agent starts acting with a user’s permissions and credentials, it can begin moving through systems on that person’s behalf. The challenge is that organizations may not have the same level of visibility, oversight, or control over the agent that they already have over the employee.

This is why securing AI agents is quickly becomes an identity and access problem. If an agent can access sensitive systems, permissions should be limited to what it actually needs. Access should not remain open forever just because it was approved once. And actions should be traceable back to the person, team or workflow that authorized them.

The basic idea is familiar. Do not give more access than necessary. Do not trust forever. And do not assume that a valid credential automatically means a safe action.

Zero Trust now has machines to think about too

Zero Trust is built around a straightforward idea: never assume trust just because something has already been authenticated. That principle becomes even more useful when the identity requesting access is not human.

Cunnigham argued that the same kinds of controls already used around people like identity, device trust, session trust and policy enforcement should also extend to agentic systems.

An agent should not get unlimited access simply because someone approved a token once. Instead, access needs boundaries. What applications can the agent reach? What tools can it use? What data can it see? What actions can it take without approval? And when should a person have to step in?

This is where Zero Trust fits naturally into securing AI agent. Verify the identity. Check the context. Limit the access. Apply policy to the action being requested. Keep reassessing whether that access should continue. The actor may be different now. The principle still works.

Put the controls where the agents actually work

Identity is important, but it is not the whole picture. AI agents interact with applications, APIs, data and increasingly the browser. Cunningham described the browser as an important control point because so much modern work, including generative AI usage, already happens there. That means security controls cannot stop at login.

Organizations also need to think about what happens after access is granted. Where can data move? What tools can an agent call? Can it move outside the task it was given? Can risky actions be blocked at runtime?

The argument was that enforcement needs to sit outside the AI model itself, across the tool, data and runtime layers. In other words, organizations should not rely on the agent to decide where the boundaries are. The boundaries need to be built around it.

This matters because agents can operate far faster than people can review their actions manually. Trying to watch everything after the fact simply does not scale. This is why the problem is bigger than staffing. It is an architecture problem. And that is also what makes it solvable.

As AI agents take on more work, the goal should not be to slow them down. It should be to make sure they can move quickly inside the right limits. That is where AI agent security is heading: not just identifying the agent, but controlling how it accesses, acts and operates across the enterprise.

FAQs

How do you decide which actions an AI agent should be allowed to perform autonomously?

A good rule is to match autonomy to risk.

Organizations should also consider how easily an action can be traced, reversed, and audited if something goes wrong.

The goal is not to give an agent as much freedom as possible, but only the level of autonomy it needs to complete its task safely.

How often should an agent’s permissions and access be reviewed?

Permissions for agents should be reviewed regularly, but the timing should depend on the level of access and risk involved.

Highly privileged agents may need much more frequent reviews, while lower-risk agents can follow a longer review cycle. Access should also be reassessed whenever an agent changes roles, connects to a new system, gains new capabilities, or is no longer actively used.

The key is to avoid treating AI agent access as permanent. Permissions should stay aligned with what the agent actually needs to do.

How should organizations offboard an AI agent?

Offboarding should include more than disabling the agent itself. API keys, tokens, active sessions, application permissions and persistent integrations may also need to be removed so the agent no longer retains access through previously granted credentials.