Why AI Agents Need More Than Threat Detection
Shashwat Sehgal is CEO and co-founder of P0 Security, helping enterprises secure runtime access across agents and users before risk happens.
gettyWhen an agent takes an action it shouldn’t, the immediate instinct is to ask, “Was it attacked?” Prompt injection, malicious tools, credential theft and weird data movement are real concerns, and security teams absolutely should detect them.
But a more basic failure is frequently behind it: The system had permission to do what it did. That’s why the first thing security teams should look into is why the agent was allowed to take that action in the first place, and whether that authority matched the organization’s intent.
Threat detection is good at watching the shape of what an agent is doing. It looks at prompts, retrieved content, tool calls, execution sequences, session history, data movement and deviations from expected behavior. These systems can flag likely compromise or unsafe activity and block or alert before damage spreads.
That matters. Still, threat detection answers a different question than access control. It’s essentially: “Does this look dangerous?” Authorization answers: “Is this action allowed here, by this actor, on this resource, for this purpose?”
Those are related, but they aren’t interchangeable. An agent can look normal—no injection, stolen credential or obvious anomaly. Yet, it can still do something wrong if it had overly broad permissions from the start.
Suppose an agent is asked to reduce cloud waste. It finds production resources it believes are unused and then deletes them. The dangerous part isn’t the intent. It’s that the agent carried credentials that made deletion possible in the first place.
If an agent runs with a broadly scoped API key, service account token, OAuth credential or cloud role, the target system treats its actions as authorized. Then, we add monitoring and detection to figure out whether the agent is using those permissions correctly.
There’s value in that. But it’s also a posture problem: Why does the agent have standing permission to begin with?
Runtime access control approaches the problem directly. You determine what authority is appropriate for the specific task and give only that. Permissions can be limited to a particular resource and action, subject to approval where needed and removed when the job is complete.
The difference shows up when something goes wrong. A compromised or mistaken agent can’t exercise permissions it never received.
Authorization gets harder in agentic systems because the identity you see at the final action can be several steps removed from the original user.
An originator (a human, machine or even another agent) asks an agent to do something. That agent may invoke another agent or a tool. Eventually, an action lands in AWS, GitHub, Salesforce, a database or some other enterprise system. By the time it hits the target, the actor identity often tells you very little. The important part is the chain of authority and the constraints attached to it.
So, what needs to be preserved is context: who originated the task, which agent is acting, what authority was delegated, what resource is being accessed, what action is being attempted and what organizational policy requires in that context.
Identity provides context. The control comes from enforcing what the agent can do.
Most companies already have policies governing production access, sensitive data, financial systems, administrative privileges and other consequential actions. Introducing agents shouldn’t create a parallel permission model.
A development agent might be allowed to read production logs but not modify production infrastructure. An IT agent may unlock an account but not add someone to a privileged group. An agent acting for a finance role shouldn’t gain access to information the human couldn’t access directly.
That’s the access-control decision. The challenge is carrying it into runtime across tool calls.
In practice, that means you don’t hand the agent a long-lived admin token and hope monitoring catches mistakes. You assign narrowly scoped permissions per task and per resource, apply policy checks before tool execution and revoke access immediately when the job is done.
This isn’t an argument against threat detection. Companies should detect prompt injection, malicious or compromised tools, behavioral anomalies, data exfiltration and other threats. Those controls provide signals and protections that access control doesn’t. But threat detection should sit alongside runtime authorization rather than replace it.
As agents become more autonomous, we have to assume some will eventually be compromised, manipulated, confused or simply wrong. A safe architecture shouldn’t depend on predicting every dangerous sequence of behavior.
Recognizing dangerous behavior is important. Constraining authority is also important. When something goes wrong, investigate both the why behind the behavior and the why behind the permission.
Because debugging behavior matters, but if you can’t explain why an agent had the authority to take the action at all, you haven’t fixed the system. You’ve only identified the symptom.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
