AI Agent Security: What You Can Protect Depends on Where You Stand
Contents
I attended the Gartner Risk Management Summit 2026, held from July 22 to 24.
The products that claim to "secure AI agents" stand in different places from product to product. 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.
Where an AI security product stands decides what it protects
None of these products are wrong; they simply stand in different places. What you settle first is not the product but which of the four kinds of AI your company is dealing with.
Figure 1: The order you decide in (start from products and no deciding factor appears / start from targets and the product follows)
An AI agent can be attacked without being reachable
For AI agents built into your own work, reachability alone no longer decides whether an attack can succeed.
Figure 2: The two attack paths (finds an opening / sends one email, the agent reads it)
The instruction that gets through is carried out by an AI agent holding your own credentials, and the ceiling on damage is set not by the privileges that could be seized but by the privileges granted in advance.
Deep dive: what turns over for the defender
Table 1: What still differs for the defender
| Dimension | Traditional attack | Attack on an AI agent |
|---|---|---|
| What becomes surface | What can be reached, counted and reduced | Wherever the agent goes to read |
| How it looks in logs | Suspicious traffic, failed logins | Indistinguishable from legitimate tool calls |
| Ceiling on damage | Privileges the attacker could seize | Privileges granted in advance |
Read-only means information leaks; the ability to update or send means work actually happens.
Company AI splits into four things to protect
The AI inside a company splits into what employees use and what the company builds in, and each of those splits in two again. Only shadow AI has no control point at all, so that one starts with finding out it exists.
Figure 3: The four things you protect (A company-issued AI / B shadow AI / C on cloud or SaaS / D in your own app)
Deep dive: what differs across the four
Table 2: Control point and records, per target
| Target | Control point | Records |
|---|---|---|
| A Company-issued AI | Contract and settings | Set by the contract |
| B Shadow AI | None | None kept |
| C On cloud / SaaS | The provider's console and API | Surface at the provider |
| D In your own app | Code you wrote yourself | None unless the builder adds them |
Shadow AI is the only one with no control point. It enters the business without passing an approval process or a design review, so as long as the company cannot see it, the work starts with finding out that it exists.
AI security products fall into ten control patterns
Lining the products from the booths up by where they stand gives ten patterns. Seven of them stop an attack on the spot; the remaining three count or test.
Figure 4: Where the ten patterns stand (the network path / the endpoint / the cloud or SaaS side / your own app / the model)
Deep dive: why identity reaches into your own app
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 and stops at its next request once you remove the privilege.
Shadow AI is reached only by patterns 1 and 2 because a paste that crosses neither the network path nor the endpoint is visible to no one. How each pattern touches things, and what it reaches, are at the end of this piece.
Prioritize AI risks before choosing products
What you decide before lining up products is how much risk sits with each target. You will work through them in order of risk.
Figure 5: How each of the four targets maps to something you can already count
Contracts and users, expenses and invoices, granted integrations, privileges and records. Every one of them can be counted inside your own company before a product is involved. What to check per target, and the trigger for adopting a product, are in the table at the end.
Where a product stands is not written on its label
Neither the product name nor the feature list tells you where a product stands. There are only three things to check: where it stands, what it reaches, and whether it stops things on the spot.
Figure 6: The three questions, and the answers you should get back
That only became clear by asking each company at their booth, so starting from a catalogue comparison will trip you up at the same place. These ten patterns come from walking the booths that led with AI agents or AI security among the 63 exhibitors at the July 2026 show, asking each vendor what their product controls and how, and sorting the answers ourselves at Pentacon Research.
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.
Appendix: the full tables
Table 3: How each pattern touches things, and what it reaches
| # | Where it stands and category | How it touches | Reaches |
|---|---|---|---|
| 1 | The path (checkpoint) / SWG, CASB | Sits inline on traffic and inspects the contents | A/B |
| 2 | Endpoint and tool doors (gatekeeper) / EDR, browser extension | Catches sends and calls just before they happen | A/B |
| 3 | Inside the tenant (auditor) / SaaS posture management | A third party's product enters the SaaS tenant by API and reads settings, privileges, and history | A/C |
| 4 | Logs (recorder) / SIEM, UEBA | Ingests them and finds anomalies after the fact | A/C/D |
| 5 | Identity (front desk) / IDaaS, IGA, PAM | Decides who gets into what, inventories privileges, and brokers credentials | A/C/D |
| 6 | The platform itself (landlord) / Cloud provider built-ins | The cloud or SaaS provider builds identity, data protection, and detection into its own product | A/C |
| 7 | Inside the app (building material) / Guardrail SDK | Sits in the application's own processing as a library and sees calls that never leave | D |
| 8 | An optional gateway (voluntary checkpoint) / AI gateway | Developers route AI calls through a path they stand up themselves | D |
| 9 | The whole cloud (satellite photo) / CNAPP, AI-SPM | Scans cloud accounts to inventory AI assets and excessive privileges | D |
| 10 | Models and testing (protection and pen testing) / Red teaming, model inspection | Attacks it to find weaknesses | C/D |
Table 4: Risk per target, and what you can check yourself
| Target | Main risk | What you can check yourself | Trigger for adopting a product |
|---|---|---|---|
| A Company-issued AI | Business data passes to an outside service | Which AI is contracted, who uses it, how sensitive the data going in is | A department putting sensitive data in, with no inspection of inputs at all |
| B Shadow AI | Internal data leaves without the company knowing, and no record of it leaving remains | Personal subscriptions visible in expenses and invoices; existing proxy or DNS logs | No idea how much there is. Not knowing the size of the blind spot is itself the trigger |
| C AI agents on cloud or SaaS | Broad integration grants left in place, and users able to add more without approval | The tenant's list of granted integrations — who, at what scope, org-wide or individual | Integrations have grown past what anyone can track by hand |
| D AI agents embedded in your own app | An agent that can update or send being driven by a document it was made to read | The privilege inventory, whether approvals exist, whether records exist | Write privileges exist, with neither approval nor records |
Visualize your attack surface with PentaTrail CTEM/ASM
From discovery to vulnerability validation and remediation — all powered by the CTEM framework.
Get Started
