Shashwat Sehgal is CEO and co-founder of P0 Security, helping enterprises secure runtime access across agents and users before risk happens.
Most companies start AI agent security by examining the agent itself: which agents exist, what systems they can reach, what permissions they have and what actions they can take. Those are reasonable questions. But they are not enough.
The harder problem is not the agent in isolation but what happens when a requester, an agent, a tool and a resource come together at runtime. By “requester,” I mean the human, service account, workload or even another agent that causes an agent to act. That distinction matters because agentic access does not always start with a person clicking a button. It may start with an automated process, another system or one agent calling another. Should this requester, through this agent, using this tool, be allowed to take this action on this resource right now?
That is where many identity and access models fail. Authentication can tell you who started a session. Agent inventory can tell you which agents exist. Logging can tell you something happened. But none of that alone determines whether the action should be allowed, given the full chain of authority behind it.
The Security Boundary Is The Full Chain Of Authority
It’s the full action chain that matters. A requester may have limited access. An agent may have a broader reach. A connected tool may expose actions the requester could not take directly. A downstream workflow may touch a system no one considered when the agent was approved. Each piece may look acceptable on its own, but the combination can create an authority the organization never intended. This is often missed when companies treat agent security as an agent-only problem.
In a traditional model, the path is direct: A user signs in, a permission check happens, access is granted or denied and the user acts. That works when the human is both requester and actor. Agents make the path less direct: The requester may initiate work, but the agent executes it. The agent may call a tool or spawn sub-agents. A tool may reach into a database, cloud console, ticketing system, code repository or production environment. One action may trigger another, and the final outcome may be several steps from the original request.
Authentication alone is not control. Control means knowing whether the requester had the right to cause the action, whether the agent stayed within scope, whether the tool was appropriate and whether the resource was allowed to be touched. It also means being able to stop, escalate or constrain the action when risk rises, then revoke access when the task ends.
Runtime Authorization Is The Missing Control Layer
This is where agentic runtime security matters. The real security decision happens at runtime: who initiated the action, which agent is acting, which tool is used, which resource is touched, what the action will do and whether the full combination should be allowed. After the action completes, if an agent finishes a task, that access should not become permanent. The same JIT principle applies: Access should be for a specific purpose, constrained to the right scope and revoked when the task, workflow, session or project is done.
Security teams are asked to approve agent use without a clear way to understand what agents can do once connected. Platform teams build agent workflows without consistent enforcement across every tool. Compliance teams seek audit trails, but logs are fragmented: the requester in one place, the agent in another, the tool somewhere else.
Fragmentation is the problem. If an agent changes a production setting, queries customer data or triggers an operational workflow, the organization needs the full path behind that action. It’s not enough to know a token was valid, an agent existed or a workflow ran. They need to know what authority was assembled in the moment and whether it should have been allowed.
For agentic systems, that becomes the real security boundary. The requester matters. The agent matters. The tool matters. The resource matters. The action matters. The runtime context matters. Looking at any single piece creates a false sense of control because risk lies in how they combine.
Companies need a practical way to govern agentic access: discover which agents exist and what they can access and connect each agent action back to the requester. They need to understand which tools, systems and resources were involved. They need policies that evaluate the full chain of action, not just the agent’s standing permissions. They need runtime controls that approve, deny, limit or escalate based on what is happening.
They also need an audit trail that leadership can understand after the fact: who or what initiated the action, which agent acted, what tool was used, what resource was touched, what the outcome was, whether the action was allowed by policy and where it should have been stopped. That is the difference between observing agent activity and governing agentic access.
It is tempting to treat agent security as a visibility problem first: Build an inventory, map the agents and watch what they do. That matters, but it only answers part of the question. Companies must govern what agents can do, on whose behalf, under what conditions and against which systems. That requires runtime authorization.
Identity still matters, but it requires more context. The requester, agent, tool and resource must be evaluated together because access in an agentic system is exercised that way. This is the start of blended identity for agents: a better understanding of the full chain of authority behind an action.
The companies that get this right will move faster with agents because they’ll have a control model that matches how agents work. They’ll know what agents can reach, who or what caused each action and whether it should be allowed. When something goes wrong, they’ll explain the chain clearly. Those that don’t will keep asking narrower questions: Who authenticated? Which agent ran? Was there a log?
Those questions matter, but they do not answer the central one: Should this requester, through this agent, using this tool, have been allowed to take this action on this resource at that moment?
How are you solving for this?
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
