What Are Your AI Agents Allowed to Do?

Most companies didn't sit down and decide to put AI agents into production. It happened a team at a time. Someone wired an assistant into a ticketing system, someone else gave one read access to the data warehouse, and now software is doing work that used to take a person and a login.

Check Point's 2026 Cloud Security Report puts numbers on it. Seventy percent of organizations run generative AI in production, and 64 percent have deployed AI agents in live environments. These agents aren't only drafting text. They query data, kick off workflows, and call other services. Twelve percent of organizations have already given agents privileged access to internal systems.

The report's harder finding is that the controls around all of this haven't kept pace. More than half of organizations have had a confirmed AI-related security incident.

The security question changed

For years, AI security mostly meant watching what people typed into a chatbot. Was someone pasting a customer list into a public tool? That's a real risk, and it's still worth watching. An agent is a different animal. It doesn't wait for a prompt. It acts.

Check Point frames the shift plainly: the job has moved from governing what users ask AI to controlling what AI systems are allowed to do. An agent with access to your systems can read records, start a process, move data between services, and call an outside API, all without a person in the loop. With 12 percent of organizations handing agents privileged access, that's a lot of autonomous activity touching real systems with, in the report's words, limited oversight.

Old controls were built for people

Most of the tools meant to catch this were designed around human behavior. Identity systems assume a person signs in, does a few predictable things, and signs out. Network monitoring looks for traffic that seems off. An agent breaks those assumptions. It's fast, it runs on API calls, and it identifies itself with a service account or an API key instead of a name and a password. Those credentials are non-human identities, and they already outnumber human accounts by a wide margin in most enterprises.

Two things make that hard to govern. The agent's traffic often looks like ordinary, legitimate API activity, so it slips past the usual alarms. And when the agent runs on a vendor's cloud, the record of what it did lives on the vendor's servers. That's part of why only 5 percent of organizations in the survey say they have full visibility into how AI is being used, and why so many can't say whether they've had an incident at all.

The fix is to shrink what an agent can reach

You can try to chase all this with more monitoring layered on top. The other path is to give the agent less room to go wrong in the first place.

That's the approach Cognetryx takes. The agents run inside your own environment, on the company's own index of documents and data, using a set of tools you define. A few things follow from that. The agent's identity is scoped and logged like any other actor in your network, so what it can touch is something you set in advance. Retrieval is permission-aware, so an agent only surfaces what the person behind the request is already cleared to see, checked at the index before anything reaches the model. And because the work happens on infrastructure you run, every prompt, source, and action is logged where you can actually get to it.

None of that depends on the agent reaching out to an outside service you can't see or log. When the model, the index, and the tools all sit inside one environment you control, the question of what an agent is allowed to do has an answer you wrote, enforced where the agent actually runs.