AI Agent Security: What You Can Protect Depends on Where You Stand

I attended the Gartner Risk Management Summit 2026, held from July 22 to 24. The exhibition floor was lined with the familiar names in zero trust and CTEM/ASM, but what most of them were leading with had become AI security or AI agent security. The lineup had barely changed; the topic had shifted to AI.

Which brings me to the products that claim to "secure AI agents." Where they stand differs from company to company. Walking the booths confirmed that the same phrase points to different things. Some sit inline on the network path, some place a guard on the endpoint, some enter a SaaS tenant through an API, some read logs after the fact, and some hand out identities. None of them are wrong, and the only real difference is where they stand — but without understanding each topology and control mechanism one at a time, selection will trip you up.

There are two kinds of AI inside a company, with different risks

The AI inside a company splits in two: AI that employees use themselves and AI agents the company builds into its work. The first group is, in practice, a mix of what the company contracted and handed out and what employees signed up for on their own. The latter is called shadow AI, and it enters the business without passing an approval process or a design review, carrying the risk that internal data leaves the company. It also bypasses tenant controls, so no audit log is produced. As long as the company cannot see it, it belongs back under governance.

For AI agents the company builds in, the shape of the attack itself changes. Traditional attack surface management counts what is visible from the outside. Open ports, exposed applications, expired certificates — things that become surface because an attacker can reach them, on the logic that shrinking the surface shrinks the risk.

That logic does not hold for AI agents. Instructions are planted in a page, an email, a ticket, or a PDF that the agent goes and reads on its own, and the moment it reads them, its objective is swapped. No port has to accept a connection. What the attacker needs is not reachability but delivery, and sending one email or filing one ticket meets the condition.

The instruction that gets through is then executed by an AI agent holding your own credentials. The blast radius is set not by the attacker's privileges but by the privileges you granted the agent. Read-only means information leaks; the ability to update or send means work actually happens.

Laid side by side, the assumptions defenders have relied on turn over one by one.

Table 1: Traditional attacks compared with attacks on AI agents

Row 4, "what sets the damage," is the one that matters most. Traditionally, how much an attacker could seize set the ceiling on damage; with AI agents, the privileges the adopting side granted in advance become that ceiling directly.

Each of the two splits in two again

The AI employees use splits into what the company contracted and handed out and shadow AI that individuals started using. The first can be handled through contracts and settings; the second starts with finding out that it exists at all.

The AI agents a company builds in also split in two: those running on a platform provided by a major cloud or SaaS vendor and those embedded into your own application. For the first, settings, privileges, and history surface in the provider's admin console and API, so governance can be applied from outside. The second runs inside code you wrote yourself, so neither a place to route calls through nor a way to keep records exists unless the builder puts one there.

The question of what to protect in AI comes down to which of these four you are dealing with, and that also settles where a product should stand.

Figure 1: The four things you protect

Products split into ten types by where they stand

Table 2: Ten types of product by where they stand

A through D are the four kinds of company AI from Figure 1. The circles and crosses show whether that type can reach the target at all.

Types 3 and 6 look at the same target, but the builder differs. Type 3 is a third party's product entering by API from outside the tenant, and it can span several SaaS platforms. Type 6 is built by the provider into its own product, so it reaches deep within that stack but not into anyone else's. Type 9 also reads from outside, but what it looks at is cloud accounts rather than SaaS tenants, counting the AI assets and privileges sitting there.

Type 5 reaches D as well, because an agent you embed yourself still needs keys to do anything. Have it fetch those connection details from the identity platform's vault rather than an environment variable, and the agent lands in the ledger as a non-human identity, receives a short-lived key scoped to the task at hand, and stops at its next request once you remove the privilege. What you hold, though, is the key and the privilege — not the contents of the prompt or the model's reasoning. As with types 7 and 8, none of it happens unless the people who built the agent write it that way.

Shadow AI, column B, gets a circle only from types 1 and 2. Unless it crosses the network path or the endpoint, an employee pasting data is visible to no one. Types 4 and 10 divide not by target but by when they take effect — the former to notice after the fact, the latter to fix things before release. The only types that stop anything at the moment it happens are those that sit inline on traffic or calls and those that can strip privileges. Rather than comparing products, deciding which of the four your AI belongs to gets you further, faster.

Before adopting anything, run a risk assessment across the four

What you decide before lining up products is how much risk sits with each target. You will work through them in order of risk.

Table 3: Risk per target, and what you can check yourself

Once you know who you are protecting, the products narrow down

What walking the booths made clear is that no product's feature set is wrong; they simply protect different places. What deserves comparison is not one product against another, but the decision you make first, in your own organization, about which of the four targets to protect first.

PentaTrail is a CTEM / ASM service that continuously surfaces your company's externally visible attack surface and carries it through prioritization and remediation. See PentaTrail / CTEM for the feature set, or Contact us to discuss adoption. To see the discovery process for yourself, Start Your 14-Day Free Trial.