AI agents are moving into the enterprise much faster than most security programs were designed to handle.
They are no longer just answering questions or generating content. Agents can read email, access SaaS applications, query databases, invoke APIs, use MCP tools, modify records and execute business workflows. In other words, AI is moving from generating answers to taking actions.
For CISOs and C-level leaders, that changes the security conversation. The question isn’t simply whether an organization is using AI safely. A more important question is: Can we confidently identify, govern, monitor, and control every AI agent before it becomes our next privileged insider?
Here are some questions I believe security and business leaders should be asking now.
Think about what makes a privileged human identity risky.
It has access to important systems, sensitive information and business processes. That’s why we put controls around administrators, privileged accounts and service identities.
Now consider an AI agent connected to Microsoft 365, Salesforce, ServiceNow, a cloud environment and internal databases.
That agent may be able to read information, make decisions, call tools and change systems—potentially in seconds and without someone approving every individual action.
The agent doesn’t need malicious intent to become dangerous.
Too much access + too much autonomy + too little oversight can create insider-like risk.
Check Point describes this shift well: AI agents are becoming enterprise workers. They don’t simply generate text; they retrieve data, use credentials, invoke tools, call APIs and execute tasks on behalf of users and workflows.
They are essential, but they aren’t enough on their own.
Traditional identity and access management (IAM) answers an important question: What is this identity allowed to access?
Agentic AI forces us to ask another: Should this agent be allowed to perform this particular action, in this context, right now?
Imagine an agent legitimately has access to a customer database. It may need READ access to do its job. But should that automatically mean it can DELETE customer records?
Probably not.
This is the difference between access control and action—or outcome—control. Check Point builds its AI agent security model on this distinction. In an agentic environment, the company argues, security stops being a question of who has access and becomes a question of what AI is allowed to do. The reason is simple: access can be valid and the outcome still wrong. A permission check can pass while the action behind it is one no reasonable operator would approve.
Organizations should establish hard boundaries around agent operations.
For example, a company could adopt a straightforward policy: No autonomous AI agent is permitted to perform a DELETE operation against production data.
An agent could be allowed to:
CREATE → Allow READ → Allow UPDATE → Allow under defined conditions DELETE → Block or require human approval
The important part is that this shouldn’t simply be written into a system prompt saying, “Please don’t delete production data.”
The security control should exist outside the agent and be technically enforced. If the agent decides deletion is the best way to accomplish its objective, enterprise security policy should still have the final word.
Yes, and Check Point’s Workforce AI Security provides a useful real-world example.
Check Point’s Workforce AI Security documentation on managing agent interactions describes visibility into AI agents operating through MCP servers and the tools exposed to them. Administrators can see agent operations categorized as Create, Read, Update and Delete (CRUD), analyze the risk associated with those capabilities and restrict access to higher-risk tools.
More importantly, Check Point’s agent policy framework explicitly addresses controlling automated actions. The control policy examples in the Workforce AI Security admin guide show how policies can define the tool or CRUD-operation scope and then apply an Allow or Block action. This matters because access control has already said yes by the time the tool call happens. An agent authenticates with an inherited token that usually carries the full operation range the system grants. Identity verification confirms who is calling; it cannot test why — and with agents consuming untrusted documents, web pages, and tool output, the request may not originate with the operator at all. Operation scope holds regardless. A delete rule blocks a delete no matter what convinced the agent to attempt one.
That’s an important evolution in cyber security. We aren’t simply observing what an agent did yesterday. We’re moving toward deciding whether an action should be permitted before it happens.
Because agents operate quickly. Imagine this sequence: Employee → AI Agent → Model → MCP Tool → API → DELETE
The agent may be authenticated. The API call may be technically valid. The agent may even believe deletion is necessary to accomplish the user’s request. But organizational policy says autonomous agents cannot delete production records. Runtime security provides a control point before that final action executes.
Check Point describes its AI Agent Security approach as evaluating prompts, model responses, external content, tool calls and agent actions in real time, allowing policies to block unsafe or unauthorized behavior before execution.
That’s a significant distinction: Permissions define what an agent can do. Runtime policy helps determine whether it should do it now.
A human.
Every production agent should have a clearly identified owner. For higher-risk agents, I’d argue for both a business owner and technical owner.
The business owner answers: Why does this agent exist, and what authority should it have? The technical owner answers: How is it configured, connected, authenticated, monitored and secured?
Agents can execute tasks autonomously. But accountability cannot be autonomous. An agent without an identifiable owner should eventually be treated much like an orphaned privileged account.
This is where the identity problem becomes particularly interesting.
Suppose malicious content manipulates an agent into calling a legitimate tool. The agent then uses valid credentials to perform an action its designers never intended.
Authentication worked.
Authorization may technically have worked.
But the behavior was wrong.
Check Point’s guidance on securing AI agents highlights prompt injection, indirect attacks, sensitive-data exposure and unauthorized tool use as risks requiring contextual runtime controls. That’s why authentication alone can’t establish permanent trust for an autonomous identity.
The principles don’t really change. Their application does. For an agent, the decision increasingly becomes:
Identity + Context + Data + Tool + Requested Action + Behavior = Trust Decision
An HR agent reading ten employee records might be perfectly normal. The same agent suddenly requesting 20,000 records deserves another look.
A development agent writing code may be expected. That same agent attempting to modify IAM policies shouldn’t inherit trust simply because it authenticated successfully.
Trust needs to remain dynamic.
We already know how to do much of this from Identity Governance. Apply the same discipline to agents:
Discover → Register → Assign Owner → Authenticate → Authorize → Monitor → Review → Suspend → Retire
When an agent is created, establish ownership. When it receives access, enforce least privilege. When its purpose changes, review its permissions. When its behavior changes, reassess trust. And when the agent is retired, revoke its credentials, tokens, API permissions and tool access.
Today’s harmless proof of concept shouldn’t become tomorrow’s forgotten privileged identity.
Start with questions that should have concrete answers:
- How many agents are operating in our environment?
- Who owns each one?
- Which agents have access to sensitive or privileged systems?
- What tools and MCP servers can they invoke?
- Which operations can they perform?
- Which actions are explicitly prohibited?
- Can we detect abnormal agent behavior?
- Can we stop a dangerous action before execution?
- Can we immediately disable an agent?
- Can we reconstruct what happened afterward?
Check Point’s Workforce AI Security follows a similar discover, govern and protect approach, providing visibility across AI applications and agents, granular governance policies and runtime controls for risky agentic actions.
Agentic AI shouldn’t be viewed only as another application-security problem.
We’re creating a new class of non-human identities with decision-making authority.
For decades, cyber security has operated on the principle of least privilege: give an identity only the access necessary to perform its job.
Agentic AI may require us to go one step further—to what I would call Least Agency: Give an AI agent only the autonomy necessary to accomplish its authorized business purpose—and no more.
Some actions can be allowed. Some should require additional context or human approval. And some actions may simply be prohibited.
That’s how we get the benefits of autonomous AI without handing over unlimited authority. The goal isn’t to slow AI adoption. It’s to make sure security evolves at the same speed. Because as agents become part of our digital workforce, the question every CISO, CIO and board should eventually be able to answer is still the simplest one:
Can we confidently identify, govern, monitor, and control every AI agent before it becomes our next privileged insider?
If the answer today is “not yet,” that’s probably where the AI security strategy needs to start.