At Opsin, transparency is a core value. Internally, almost everything we know is shared by default. This memo is that value pointed outward: the view we've formed after hundreds of conversations with CISOs and security teams trying to secure AI. I'd rather argue it in public than keep it in a deck.
Here's what we keep hearing: every vendor in agentic AI security sounds identical. Same words: “runtime,” “guardrails,” “agentic,” “posture,” “Zero Trust for AI.” Same promises. One CISO summed it up better than I could: “This is a mushroom market." Things sprout overnight, in the dark, and nobody’s sure which ones are safe to eat.
It isn’t only buyers who feel this. Cisco’s own security leadership has written that “AI security” has become an overloaded bucket: when a CISO says it, they might mean protecting AI from attackers, using AI to catch attackers, stopping data from leaking into AI tools, or stopping AI from producing harmful output. The honest answer to “which one?” is usually all of the above. Which is the whole problem. Trade press covering the category has reached the same verdict: the pitches have converged to the point where messaging no longer differentiates anyone.
So this piece tries to do three things: explain why everyone sounds the same, offer a cleaner way to cut the market, and hand you, if you're the one buying, a rubric to tell these tools apart.
The confusion isn’t mostly vendors being cynical. It's that there are several legitimate ways to slice this market, and people blur them in the same breath.
You can cut it by control layer — identity, data, model, network, application. Most analysts do; Gartner’s AI TRiSM and Forrester’s AEGIS are both, underneath, control-layer models.
You can cut it by lifecycle stage — securing AI as it’s built, deployed, and run. Red-teaming a model before launch and policing it at runtime are different businesses.
And you can cut it by where the agent runs — on a laptop, inside a cloud platform, behind your app. This is the one everybody reaches for first, because it’s the most concrete.
When a vendor describes themselves on one of these and you're judging them on another, of course it sounds like mush.
But here’s the cut that finally made the market legible for me, and it's the one I’d build the whole conversation around: where the agent runs is a proxy. The principle underneath it is ownership — who built the agent, and who’s on the hook to secure it. Slice the market that way and it stops being a mushroom patch. It becomes three very different problems with three very different owners.
Two of these three have a home.
And then there's the third category:
That’s not a runtime-location problem. It's a governance gap created by the democratization of AI development: for the first time, the person building a powerful, data-connected agent is often not a developer and never touches a security review.
It’s worth being precise about why the tools you already own don't cover this. AppSec secures code your engineers write. Endpoint security secures devices. Neither was built for the situation that defines business-built AI: a non-developer granting an agent their own (often over-broad) access to enterprise data, through a platform’s native interface, with no code and no review in the loop.
To control the situation, security needs identity-aware and data-aware context: who can this agent act as, what can it reach, and should it be able to? Yet, that's a layer: data and identity governance for AI — that sits between the AppSec stack and the endpoint stack, owned by neither. That’s the orphan.
If you have budget for one thing, the evidence says it shouldn’t be prompt injection. Gartner projects that through 2026, at least 80% of unauthorized AI transactions will come from internal causes — oversharing, unacceptable use, AI behaving in ways it shouldn’t — rather than malicious attacks. Not 80% traced to a clever adversary. 80% from inside your own walls.
The field data agrees. A 2026 Cloud Security Alliance survey found that 82% of organizations already have AI agents running that they didn’t know about, and nearly two-thirds had hit an agent-related incident in the past year — 61% of them reporting data exposure as the result. OWASP now lists sensitive-information disclosure and excessive agency as categories separate from prompt injection, because they are separate problems — and the disclosure ones are far more common.
Read those numbers against the three categories above and the picture is hard to miss. The dominant risk isn't the adversary attacking your developer-built app. It’s the orphaned, business-built agent quietly oversharing data it was handed too much access to. The highest-probability risk sits squarely in the category nobody in security owns.
And this category doesn’t just lack an owner; it moves too fast to police by hand. The old path to enterprise software ran through stages: a business user filed a request, engineering built it, security reviewed it, and only then did it launch. Slow, but security got its checkpoint. Today that same business user stands up an agent in fifteen minutes: inside the platform, no ticket, no review and does it again next week. No security team can manually inspect every one of those before it goes live. The checkpoint wasn’t removed; the build simply outran it. That’s the real case for automation here: at the speed and volume these agents are actually created, continuous, automated enforcement isn’t a convenience. It’s the only thing that scales.
I’ll be transparent about my bias: the orphan is the category Opsin was built for. We secure the agents your business users are building on enterprise AI platforms: Copilot, Copilot Studio, ChatGPT Enterprise, Gemini, Claude for Work, Agentforce by continuously finding and fixing the oversharing and excessive access those agents inherit, before you turn them on and continuously after.
The failure mode I see most across this market is tools that stop at posture: a report telling you you’re exposed, which then becomes your problem to act on. The harder, more valuable job is turning that intent into enforcement: catching oversharing as it happens, remediating it, and keeping the gap closed as access sprawls and new agents appear. That’s the work we chose.
You don’t have to take my word that this category matters. Take Gartner’s and CSA’s. But you should pressure-test whether any vendor, us included, actually does what it claims. Which brings me to the part that’s useful no matter what you buy.
If you’re staring at twenty decks that sound the same, stop comparing feature lists. Compare on these eight dimensions instead:
Run a POC in your own environment. Ask each vendor what they can’t do. The good ones will have an answer ready.
One more thing to price in: this market is consolidating fast, and the point categories are being absorbed into platforms as we speak. In barely a year, Palo Alto bought Protect AI, Cisco bought Robust Intelligence and then Astrix, Check Point bought Lakera, SentinelOne bought Prompt Security, Crowdstrike bought Pangea, and Cato bought Aim Security.
The lesson for buyers isn’t “wait for the platforms.” It’s that platforms acquire the easy layers first: the firewall, the scanner, the developer-built world and the hard one last: identity-aware, data-aware governance of the business-built agents sprawling across messy enterprise SaaS. That’s the orphan, and it’s the layer I’d be slowest to assume my platform vendor has already solved. Re-check that assumption every quarter. The day Microsoft, Palo Alto, or CrowdStrike genuinely closes that gap for Copilot and Agentforce natively is the day the math changes.
Microsoft can govern Microsoft but it won’t close the governance gap when organizations are deploying Microsoft AND Salesforce, ServiceNow, Google, OpenAI, Anthropic, and whatever comes next.
The market is confused because we’ve let it be: several surface cuts mashed into one vocabulary, until everything sounds the same and nothing sounds true. The way out is a sharper question. Not where does the agent run, but who built it, and who's responsible for securing it. Ask that, and three different problems with three different owners fall out, and one of them, the business-built orphan, is both the most exposed and the least defended.
We’re opinionated about that. We should be. Opsin lives in the orphaned category. But the rubric above works no matter where you land. Use it. And if a vendor can’t tell you, in one sentence, which of the three they secure and what they don’t, that’s your answer.
Which category do you think is most under-served and who in your org actually owns securing it? I’d genuinely like to know. That’s the kind of disagreement that makes this market a little less of a mushroom patch.
At Opsin, transparency is a core value. Internally, almost everything we know is shared by default. This memo is that value pointed outward: the view we've formed after hundreds of conversations with CISOs and security teams trying to secure AI. I'd rather argue it in public than keep it in a deck.
Here's what we keep hearing: every vendor in agentic AI security sounds identical. Same words: “runtime,” “guardrails,” “agentic,” “posture,” “Zero Trust for AI.” Same promises. One CISO summed it up better than I could: “This is a mushroom market." Things sprout overnight, in the dark, and nobody’s sure which ones are safe to eat.
It isn’t only buyers who feel this. Cisco’s own security leadership has written that “AI security” has become an overloaded bucket: when a CISO says it, they might mean protecting AI from attackers, using AI to catch attackers, stopping data from leaking into AI tools, or stopping AI from producing harmful output. The honest answer to “which one?” is usually all of the above. Which is the whole problem. Trade press covering the category has reached the same verdict: the pitches have converged to the point where messaging no longer differentiates anyone.
So this piece tries to do three things: explain why everyone sounds the same, offer a cleaner way to cut the market, and hand you, if you're the one buying, a rubric to tell these tools apart.
The confusion isn’t mostly vendors being cynical. It's that there are several legitimate ways to slice this market, and people blur them in the same breath.
You can cut it by control layer — identity, data, model, network, application. Most analysts do; Gartner’s AI TRiSM and Forrester’s AEGIS are both, underneath, control-layer models.
You can cut it by lifecycle stage — securing AI as it’s built, deployed, and run. Red-teaming a model before launch and policing it at runtime are different businesses.
And you can cut it by where the agent runs — on a laptop, inside a cloud platform, behind your app. This is the one everybody reaches for first, because it’s the most concrete.
When a vendor describes themselves on one of these and you're judging them on another, of course it sounds like mush.
But here’s the cut that finally made the market legible for me, and it's the one I’d build the whole conversation around: where the agent runs is a proxy. The principle underneath it is ownership — who built the agent, and who’s on the hook to secure it. Slice the market that way and it stops being a mushroom patch. It becomes three very different problems with three very different owners.
Two of these three have a home.
And then there's the third category:
That’s not a runtime-location problem. It's a governance gap created by the democratization of AI development: for the first time, the person building a powerful, data-connected agent is often not a developer and never touches a security review.
It’s worth being precise about why the tools you already own don't cover this. AppSec secures code your engineers write. Endpoint security secures devices. Neither was built for the situation that defines business-built AI: a non-developer granting an agent their own (often over-broad) access to enterprise data, through a platform’s native interface, with no code and no review in the loop.
To control the situation, security needs identity-aware and data-aware context: who can this agent act as, what can it reach, and should it be able to? Yet, that's a layer: data and identity governance for AI — that sits between the AppSec stack and the endpoint stack, owned by neither. That’s the orphan.
If you have budget for one thing, the evidence says it shouldn’t be prompt injection. Gartner projects that through 2026, at least 80% of unauthorized AI transactions will come from internal causes — oversharing, unacceptable use, AI behaving in ways it shouldn’t — rather than malicious attacks. Not 80% traced to a clever adversary. 80% from inside your own walls.
The field data agrees. A 2026 Cloud Security Alliance survey found that 82% of organizations already have AI agents running that they didn’t know about, and nearly two-thirds had hit an agent-related incident in the past year — 61% of them reporting data exposure as the result. OWASP now lists sensitive-information disclosure and excessive agency as categories separate from prompt injection, because they are separate problems — and the disclosure ones are far more common.
Read those numbers against the three categories above and the picture is hard to miss. The dominant risk isn't the adversary attacking your developer-built app. It’s the orphaned, business-built agent quietly oversharing data it was handed too much access to. The highest-probability risk sits squarely in the category nobody in security owns.
And this category doesn’t just lack an owner; it moves too fast to police by hand. The old path to enterprise software ran through stages: a business user filed a request, engineering built it, security reviewed it, and only then did it launch. Slow, but security got its checkpoint. Today that same business user stands up an agent in fifteen minutes: inside the platform, no ticket, no review and does it again next week. No security team can manually inspect every one of those before it goes live. The checkpoint wasn’t removed; the build simply outran it. That’s the real case for automation here: at the speed and volume these agents are actually created, continuous, automated enforcement isn’t a convenience. It’s the only thing that scales.
I’ll be transparent about my bias: the orphan is the category Opsin was built for. We secure the agents your business users are building on enterprise AI platforms: Copilot, Copilot Studio, ChatGPT Enterprise, Gemini, Claude for Work, Agentforce by continuously finding and fixing the oversharing and excessive access those agents inherit, before you turn them on and continuously after.
The failure mode I see most across this market is tools that stop at posture: a report telling you you’re exposed, which then becomes your problem to act on. The harder, more valuable job is turning that intent into enforcement: catching oversharing as it happens, remediating it, and keeping the gap closed as access sprawls and new agents appear. That’s the work we chose.
You don’t have to take my word that this category matters. Take Gartner’s and CSA’s. But you should pressure-test whether any vendor, us included, actually does what it claims. Which brings me to the part that’s useful no matter what you buy.
If you’re staring at twenty decks that sound the same, stop comparing feature lists. Compare on these eight dimensions instead:
Run a POC in your own environment. Ask each vendor what they can’t do. The good ones will have an answer ready.
One more thing to price in: this market is consolidating fast, and the point categories are being absorbed into platforms as we speak. In barely a year, Palo Alto bought Protect AI, Cisco bought Robust Intelligence and then Astrix, Check Point bought Lakera, SentinelOne bought Prompt Security, Crowdstrike bought Pangea, and Cato bought Aim Security.
The lesson for buyers isn’t “wait for the platforms.” It’s that platforms acquire the easy layers first: the firewall, the scanner, the developer-built world and the hard one last: identity-aware, data-aware governance of the business-built agents sprawling across messy enterprise SaaS. That’s the orphan, and it’s the layer I’d be slowest to assume my platform vendor has already solved. Re-check that assumption every quarter. The day Microsoft, Palo Alto, or CrowdStrike genuinely closes that gap for Copilot and Agentforce natively is the day the math changes.
Microsoft can govern Microsoft but it won’t close the governance gap when organizations are deploying Microsoft AND Salesforce, ServiceNow, Google, OpenAI, Anthropic, and whatever comes next.
The market is confused because we’ve let it be: several surface cuts mashed into one vocabulary, until everything sounds the same and nothing sounds true. The way out is a sharper question. Not where does the agent run, but who built it, and who's responsible for securing it. Ask that, and three different problems with three different owners fall out, and one of them, the business-built orphan, is both the most exposed and the least defended.
We’re opinionated about that. We should be. Opsin lives in the orphaned category. But the rubric above works no matter where you land. Use it. And if a vendor can’t tell you, in one sentence, which of the three they secure and what they don’t, that’s your answer.
Which category do you think is most under-served and who in your org actually owns securing it? I’d genuinely like to know. That’s the kind of disagreement that makes this market a little less of a mushroom patch.
