Tuskira Named in the 2026 Gartner® Research Note, Agentic Security: Preemptive Exposure Management

Tuskira has been named in the 2026 Gartner® research note, Agentic Security: Preemptive Exposure Management Demands AI-Driven Validation and Autonomous Interdiction, published 28 September 2026.

What the research covers

The research is directed at product leaders building exposure management offerings, and it examines what those platforms have to deliver as AI-enabled attackers move faster than remediation cycles. The following quotes are reproduced verbatim from the research.

“AI-driven attacks make discovery, visibility and risk scores insufficient as stand-alone security outcomes.”

“By 2028, more than 50% of enterprise exposure assessment platforms will natively deliver AI-driven validation through agentic adversarial testing, predictive modeling or both — up from less than 10% today — making evidence of exploitability a standard buying criterion rather than a differentiating feature.”

“By 2028, at least 30% of security platforms with exposure management capabilities will natively support autonomous or semi-autonomous interdiction through integrations with network, identity, endpoint, cloud or application controls — up from less than 5% today — shifting competitive evaluation from exposure discovery to attack-path disruption and measurable risk reduction.”

Source: Gartner, Agentic Security: Preemptive Exposure Management Demands AI-Driven Validation and Autonomous Interdiction, Luis Castillo, Elizabeth Kim, Tom Powledge, Mitchell Schneider, Craig Lawson, 28 September 2026.

The views that follow are Tuskira's own.

The list stopped being the product

There was a period where finding things was genuinely hard, and a tool that found more things than the last tool was worth buying on that basis alone. That period is over. Discovery now ships inside almost everything: the cloud platform, the endpoint agent, the code repository, the identity provider, the CI pipeline. Every one of them produces findings, and most of them produce more findings this quarter than last.

The consequence is that the number on the dashboard stopped being a measure of security and became a measure of instrumentation. A team with a hundred thousand findings is not less safe than a team with ten thousand. It is more thoroughly scanned. Nobody outside the security organization can tell those two situations apart, which is part of why exposure programs are so hard to explain upward.

What a security leader is actually accountable for is narrower and harder: which of these could an attacker use, and what did we do about it. Neither question is answered by the list.

Prioritization is a ranking. Validation is evidence.

Most programs try to close that gap with prioritization. Score the finding by severity, by asset criticality, by exploit availability, by internet exposure, by whatever context the platform can reach. The output is a better-ordered list.

A better-ordered list is still a list of guesses. Severity scores describe a vulnerability in the abstract, not the vulnerability sitting in your environment behind your controls. A critical CVE on a host that is unreachable from anywhere an attacker can stand is not a critical risk to you. A medium on a service that is internet-facing, unauthenticated, and one hop from a system holding customer data might be the most urgent thing you own. Prioritization cannot tell those apart with confidence, because it is reasoning about properties rather than testing behavior.

Validation is a different act. It asks whether the path completes, against the controls as they are configured right now, and it produces an artifact you can show someone: this sequence of steps ran, this control stopped it here, this one did not. That artifact is what converts an argument into a decision. It is also what makes it defensible to take automated action, which matters more than it sounds like, because the entire reason teams do not automate remediation is that they cannot justify the risk of being wrong.

There is a second effect that people underestimate. Validation removes work. In most environments a large share of findings turn out to be already interrupted by something the organization already deployed and already pays for. Those findings do not need action; they need to stop consuming attention. Knowing which ones they are is worth as much as knowing which ones are real.

The window between proven and fixed

Say you have done all of that. The path is validated. It is real, it is reachable, and it ends somewhere that matters. Now what?

The honest answer at most organizations is: a ticket, a queue, and a wait. Root-cause fixes are slow for reasons that are mostly legitimate. Patching a production dependency means regression testing. Refactoring an over-permissioned role means finding out what actually uses it. Rebuilding an image means a release window. Those constraints are not laziness or dysfunction, they are what it costs to change a system that people depend on without breaking it.

But the attack path does not pause while the change advisory board meets. The interval between knowing a path is exploitable and having removed the reason it exists is the most dangerous period in the whole lifecycle, precisely because it is the period where you have the least excuse. You knew. It was documented. It was open anyway.

This is the part of the problem most exposure tooling does not touch, because closing it requires doing something to the environment rather than reporting on it.

Pick the chokepoint, not just an action

The naive version of acting on a validated path is to fix the thing at the start of it. Frequently that is the worst available option: it is the slowest change, it belongs to a team that does not report to you, and it only addresses one path.

Attack paths in real environments overlap heavily. The same gateway, the same role, the same flat network segment, the same missing egress restriction shows up in path after path. If you have the full graph rather than a list, you can see where the paths cross, and a single control change at that crossing point breaks all of them at once. That is a fundamentally different economics than working a queue.

Choosing well means weighing two things at the same time: how many validated paths does this break, and how much could this change disrupt. A WAF rule that neutralizes an exploitable endpoint is reversible in seconds and affects one application. Revoking an identity entitlement may break a nightly job nobody documented. Both might close the path. They are not equivalent decisions, and a platform that treats them as interchangeable will lose the operator's trust the first time it guesses wrong.

Governed autonomy is the only kind that ships

Every serious conversation about autonomous action in security ends up in the same place: the customer wants the outcome and does not want the surprise. The way through is not to promise better judgment. It is to make the system legible and reversible.

That means the platform states which path it is closing and shows the evidence. It predicts the blast radius before it acts. It offers a simulation mode so the change can be inspected before it is real. It respects policy about which control classes can be touched without a human, which need approval, and which are never automatic. It rolls back cleanly. And it retests afterward, because an action that was not verified is a belief, not a result.

Autonomy earned this way expands over time. Teams typically start by letting the system recommend, then let it stage changes for approval, then let it execute a narrow set of reversible control types on its own. That progression is the product working correctly, not a limitation of it.

How Tuskira does this

Tuskira unifies security context across the stack: exposures, assets, identities, business context, and crucially the configuration and coverage of the controls already deployed. That last part is what most platforms lack and what makes the rest possible, because you cannot reason about whether a path is interrupted if you cannot see what is standing in the way.

On top of that graph, agents continuously and safely simulate whether validated paths complete against the current configuration. Where a path does complete, Tuskira identifies the chokepoint with the most leverage, selects a mitigation appropriate to the control that can enforce it, and recommends, stages or executes that change according to the policy the customer set. Then it retests the path and records the outcome as defended, still exposed or closed, with the evidence attached.

The measure we care about is not how many exposures we surfaced. It is how many validated paths no longer complete, and how quickly that happened after they were proven.

Read the research

Gartner clients can access Agentic Security: Preemptive Exposure Management Demands AI-Driven Validation and Autonomous Interdiction through the Gartner website.

Gartner, Agentic Security: Preemptive Exposure Management Demands AI-Driven Validation and Autonomous Interdiction, Luis Castillo, Elizabeth Kim, Tom Powledge, Mitchell Schneider, Craig Lawson, 28 September 2026.

GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and is used herein with permission. All rights reserved.

Gartner does not endorse any vendor, product or service depicted in its research publications and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner's research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.