Two Kinds of Companies: The Ones Who Know Their Employees Run AI Agents, and the Ones Who Don't

There are only two kinds of companies today: the ones that know their employees are running AI agents, and the ones that do not know it yet. There is no third category where it is not happening. The uncomfortable part, for leadership, is that the heaviest users are often not the interns. A recent survey work by UpGuard found that executives report the highest rate of regular “shadow AI” use of any group in the organization. The people setting the policy are frequently the ones quietly working around it.

Shadow AI is not “employees pasting into a chatbot”

It is tempting to picture shadow AI as someone dropping a paragraph into a consumer chatbot. That was last year’s problem. What is spreading now is autonomous agents: software that does not just answer a question but takes action, reads from systems, calls tools, and makes decisions on a loop with real permissions behind it (The user’s permissions, which can be wide).

The scale is already past the point of casual. According to Netskope’s 2026 cloud and threat research, close to half of generative-AI users reach those tools through personal accounts that sit entirely outside enterprise controls, spread across a long tail of distinct applications per organization. Each of those is a channel your security team cannot see, log, or revoke.

When an agent is involved rather than a chat window, the risk profile changes in three specific ways that we covered in depth in our introduction to AI security:

• Agents are non-human identities, and they now dominate. In enterprise clouds, non-human identities already outnumber human ones by a wide margin. An agent operates continuously holds standing permissions, and rarely gets the scrutiny a human account would. A compromised agent credential does not give an attacker a foothold to escalate from. It may already grant production access.
• Agents can be steered by their input. Large language models cannot reliably separate an instruction from the content they are asked to process. A document, an email, or a web page can carry hidden instructions that redirect the agent into misusing the access it legitimately holds. This is prompt injection, and it is no longer theoretical.
• The blast radius is decided by permissions, not intent. A read-only agent is a manageable risk. An agent that can write to a database, send mail on someone’s behalf, or change a configuration is a different proposition entirely.

Put those together with a channel nobody can see, and the cost shows up in the numbers. IBM’s 2025 Cost of a Data Breach analysis found that breaches involving shadow AI carried roughly 670,000 dollars in additional cost on average, and that only about a third of organizations had any policy to manage or detect AI use at all.

Why blocking does not work

The instinct is to ban it. Block the domains, forbid the tools, write it into the acceptable-use policy, and move on. This fails, and it fails for a reason worth sitting with: the demand is real, and people route around a wall.

• They email the file to a personal address and run it from a laptop you do not manage (it can be caught but often after the facts).
• They photograph the screen with a phone and retype the sensitive part elsewhere.
• They open a personal account on their own device and paste at will.
• They expense a subscription under a category nobody audits.

This is not hypothetical friction. Software AG found that 46 percent of employees said they would keep using AI tools even if their employer banned them. A ban does not remove the behavior. It removes your visibility into the behavior, which is strictly worse: the work still happens, on infrastructure you do not control, with data you can no longer trace.

We have watched this movie before. Shadow IT, then bring-your-own-device, then unsanctioned SaaS: each wave arrived, each was met first with a prohibition, and each was ultimately won not by blocking but by offering a governed alternative that was good enough that people stopped going around it. Autonomous agents are simply the fourth wave. The organizations that treat them as a policy violation will spend the next two years losing visibility. The ones that treat them as demand to be met will spend it building governance.

The move is to offer it, on your terms

Evidence for this is not just historical. When organizations provide a sanctioned alternative, unauthorized tool use drops sharply. One body of research puts the reduction at as much as 89 percent once an approved option exists. People are not trying to evade you. They are trying to get work done, and they will use the safe path if you build one.

For a leader, that reframes the whole decision process. You are not choosing whether your company adopts agents. That choice was made for you by your own workforce. You are choosing whether it happens somewhere you can see it or somewhere you cannot.

Why it belongs on your cloud

Once you accept that you should offer the capability, the question is where it should run. The strongest answer is the cloud you already operate, using a managed foundation-model service such as Amazon Bedrock and its agent runtime. Not because of the branding, but because of four properties that a personal account can never give you:

• The same identity model you already govern. An agent on your cloud is a non-human identity with an IAM role. It lives inside the same authorization system, the same boundaries, and the same review process as the rest of your infrastructure. You are not inventing a new control plane for AI.
• The same observability and audit trail. Every action the agent takes is logged where your existing monitoring already looks. When something goes wrong, there is a record, in the place your team already knows how to read.
• The spend lands in your cloud bill. Instead of a scatter of personal cards and unaudited subscriptions, consumption shows up as a line item you own, can forecast, and can attribute.
• Your intellectual property stays yours. This is the part most leaders underrate. Bedrock’s next-generation inference engine, Mantle, is built for zero operator access: there is deliberately no technical path for the provider’s own operators to reach your data, no interactive access tooling installed at all, hardware-backed attestation on the systems that handle model weights, and a guarantee that your prompts are never used to train a model and never leave the provider’s infrastructure. A consumer chatbot account cannot make that promise. Your proprietary data, run through a governed agent on your cloud, is protected by design in a way that a file pasted into a personal tool never will be.

None of this requires your leadership to become AI engineers. It requires meeting a demand that already exists in a place that happens to come with the controls you already trust.

The question that remains: what can it do, and who can prompt it

Offering agents on your cloud closes the visibility gap. It does not, on its own, make the agents safe. Reviewing the security of an autonomous agent is genuinely hard, and when you strip it to first principles, it comes down to two questions:

1. What can this agent actually do? Not what it was designed to do. What can the permissions behind it reach, in the worst case, if it is tricked or misused?
2. Who can prompt it? Which humans, and which other systems, can put instructions in front of it, and therefore borrow the access it holds?

These are exactly the questions that are hard to answer by hand. An agent’s real reach is the transitive closure of its role, the resources that role can touch, and the paths that lead outward from there. Its real set of callers is a graph, not a list. This is the same problem we argued in our introduction to AI security that the industry has to solve: not adding more findings to an overwhelmed stack, but making the actual risk legible to the people who have to sign off on it.

How PanIAM makes those two questions answerable

This is where we come in, and it is concrete rather than aspirational. PanIAM models your cloud as an authorization graph: every identity, every permission, every resource, and every path that connects them. That graph is exactly the machinery the two questions need, and we now apply it to agents.

• It surfaces the agents you already have. Every agent is a non-human identity, and PanIAM already inventories those across your cloud, including the ones a team set up up without telling security. When an agent sits on a large amount of reachable access, it rises to the top of your risk concentrations instead of hiding in a console nobody opens.
• It answers “what can it do.” PanIAM folds each agent into its execution role and computes the transitive closure of that role: the true worst-case reach, not the intended scope. The buckets it can read, the tables it can write, the further roles it can go on to assume. If a single prompt could turn the agent against you, this is the blast radius.
• It answers “who can prompt it.” PanIAM computes the set of principals, human and machine, that can invoke, modify, or create the agent, including the prompt-injection paths where untrusted input becomes an instruction. Each of those is a way to borrow the agent’s access without ever stealing a credential.
• It tells you the cheapest way to close the gap. Some risks are one over-broad permission away from fixed. Others, like exposing a role-bearing agent to open invocation, are structural. PanIAM computes the smallest set of changes that actually severs a dangerous path, so remediation is a short list rather than a rewrite.
• It makes the answer reviewable. All of this is presented as a graph a person can read ad sign off on, which turns the security review of an agent from an impossible manual exercise into a concrete decision.

The companies that win the next few years will not be the ones that kept agents out. They will be the ones that brought them in where they could be seen, governed, and answered for. The first move is deciding which of the two kinds of company you want to be.