9 application security startups combating AI risks

For the past several years, application security has been organized around a relatively stable model: developers write code, pipelines build and test it, and runtime controls attempt to catch what slips through. Each stage had its own tools, its own teams, and its own assumptions about where risk lived.

That model is breaking.

At RSAC 2026, the most interesting startups weren’t just adding “AI” to existing categories. They were responding to a more fundamental shift: AI is compressing the software development life cycle, blurring the lines between writing code, deploying it, and operating it. In many cases, those steps are now happening simultaneously, or being driven by the same AI agents.

The result is not just more software. It’s a collapse of security boundaries. And when those boundaries collapse, so do the traditional control points security teams have relied on.

Across the early-stage and next-stage exhibitors at this year’s conference, a familiar pattern is picking up speed. Security continues to shift left and down:

  • Left into requirements and intent,
  • Left into the tools that generate code,
  • Left into the pipelines that assemble and ship code, and
  • Down into the runtime environments where code executes.

The following startups illustrate how those control points are shifting, and why the old assumptions about where to enforce trust no longer hold.

AppSentinels: Securing workflows, not just endpoints

A company with roots in API security (see our RSAC 2025 writeup), AppSentinels has expanded its scope to address security needs in AI-driven systems. As AI agents and services increasingly interact through APIs, the risk is no longer limited to individual endpoints. It lies in how those endpoints are chained together.

The company’s focus is on understanding and securing how APIs are used in combination, rather than in isolation. “It’s not a single endpoint… it’s the way workflows are stitched together,” said Puneet Tutliani, AppSentinels co-founder and CEO. That stitching is where problems emerge.

Agents can automate complex sequences of actions across APIs, often at machine speed. In doing so, they can expose logic flaws, bypass controls, or create unintended side effects that would be difficult to trigger manually. Traditional API security tools, which focus on individual requests or endpoints, are not well-suited to detect this kind of behavior.

AppSentinels addresses this by combining continuous testing with runtime governance, attempting to model and monitor workflows as they execute. A recent addition to the product suite is explicit support for agent-driven interactions, including visibility into which agents are operating and how they use APIs and tools.

This is a natural evolution of the company’s earlier positioning. AppSentinels is still focused on protecting business logic, but that logic now includes AI agents as first-class participants.

The challenge is complexity. Modeling workflows across multiple APIs, services, and agents is inherently difficult, and many organizations are still struggling to inventory their endpoints, let alone understand how they interact. But as applications become more composable and agent-driven, achieving that visibility becomes ever more urgent.

Aurva: Tracking identity and access in an agent-driven world

If AppSentinels focuses on the seams in workflows, Aurva focuses on the who, or what, is actually performing the work.

In our 2025 coverage, Aurva centered on runtime data visibility and how information flows through applications. This year, that story has shifted toward identity and access, particularly in the context of AI agents.

The underlying issue is that agents often require broad permissions to function. They access APIs, query data stores, and interact with multiple systems on behalf of users. In doing so, they create complex chains of identity and authorization that are difficult to track and even harder to constrain.

Aurva’s approach is to monitor those chains in real time, correlating activity at the kernel level with identity and access data to understand what agents are doing, what data they are accessing, what permissions they use, and how they are using those permissions. The problem is not just visibility, but understanding agent behavior, Aurva CEO Apuru Garg said.

That distinction matters. Traditional identity and access management systems define what should be allowed. Aurva attempts to show what is actually happening, and where permissions may be broader than necessary.

At present, the platform is largely focused on detection and analysis rather than enforcement. That limits its ability to act as a direct control point, but it still fills a gap. As agents become more autonomous, the ability to trace their actions across systems becomes a prerequisite for any meaningful access control.

The question is how quickly organizations will move from observing these behaviors to actively constraining them.

Backline: Closing the loop between finding and fixing

Security startups often take aim at novel problems of cybersecurity. Backline focuses on one of the oldest challenges: what happens after vulnerabilities are found.

For years, application security has excelled at generating findings. It has been far less effective at ensuring those findings are actually fixed. Backline’s premise is that this gap is widening. As AI accelerates development, the volume of vulnerabilities increases, but the capacity to remediate them scales at a slower rate.

The company’s answer is to automate the remediation process itself.

Backline integrates with repositories and CI/CD systems to identify exploitable vulnerabilities, generate fixes, and validate those fixes through existing build and test workflows. The goal is not just prioritization, but end-to-end closure. As Backline co-founder and VP of R&D Aviad Chen described it, “The question is no longer which vulnerability matters, but how do you fix it at scale.”

Where earlier tools focused on triage, Backline is trying to compress the entire loop from detection to resolution into a single automated process. In theory, that allows teams to keep pace with the increased output of AI-driven development.

The risk, of course, is introducing new errors. Automatically generated fixes must be correct, context-aware, and safe to deploy. Backline attempts to check all of those boxes by validating changes inside the pipeline before they reach production, but this is an area where organizations will expect proof over time.

Still, the direction is clear. In an environment where vulnerabilities can outpace human remediation, automation is moving from a convenience to a necessity.

Backslash: Securing the AI development toolchain

In traditional software development pipelines, the path from idea to code was relatively controlled. Today, that path often runs through a growing set of AI tools: coding assistants, agents, plugins, Model Context Protocol (MCP) servers, and external services, many of which operate outside formal oversight.

Backslash focuses on that “in-between” layer — the AI development toolchain.

The company provides visibility into which AI tools and agents are being used across an organization, along with policy controls and guardrails governing how they interact. More importantly, it attempts to control how data moves between those components, addressing risks like prompt injection and unintended data exposure.

The underlying insight is that the attack surface is no longer just the codebase. It is the entire chain of tools that transform intent into output. As Backslash Field CTO Gil Friedman explained, security teams are no longer dealing with a single developer writing code, but with tools that sit in between the initiative and the output.

That shift has two consequences. First, security teams often lack even basic visibility into which AI tools are in use, especially as non-developers adopt them. Second, traditional controls like network monitoring or endpoint detection struggle to capture the interactions between agents, plugins, and local processes.

Backslash’s answer is an endpoint-level “guardian” that inventories these components, evaluates their risk, and enforces policies regarding what can be installed or executed.

The challenge, as with many emerging categories, is clarity. The terminology (agents, MCPs, skills, etc.) continues to evolve, and the boundaries between categories also are still forming. Yet the problem is urgent: now that AI tools are part of the development pipeline, they need to be secured as such.

Chainloop: Building governance into the software factory

Chainloop addresses a different failure point exacerbated by AI-powered development: what happens when AI accelerates everything else.

As development speeds up, governance becomes the bottleneck. Chainloop serves as a software supply chain control plane, capturing artifacts across the entire pipeline — code changes, build outputs, scan results, and deployments — to create a central, verifiable system of record. It also applies policy-as-code guardrails that automatically enforce requirements across the pipeline.

The company is not trying to be another scanning tool. It is trying to become the system that defines and enforces how software moves from commit to production.

The motivation is straightforward: AI is dramatically accelerating the “inner loop” of development, but the “outer loop” — security, compliance, and governance — has not kept pace. As Chainloop co-founder and CEO Daniel Liszka described it, organizations can now generate and ship code faster than ever, but integration, compliance, and security are still slow. Chainloop’s answer is to automate that outer loop.

By defining guardrails as code and tying them directly to pipeline events, the platform enables real-time feedback loops, including for AI agents themselves. In practice, that means agents can iterate on code or configurations until they meet defined policies, rather than relying on manual review.

This is one of the more consequential shifts on display at RSAC this year. Governance, long treated as friction, is being reframed as infrastructure, something that must be automated if AI-driven development is to scale.

The trade-off is complexity. Chainloop’s model requires organizations to think in terms of systems, provenance, and policy frameworks, not just tools. But for teams already grappling with software supply chain risk, that abstraction may be exactly what’s needed.

FireTail: Gaining visibility into AI usage across the organization

Described as an end-to-end AI security platform, FireTail takes a step back to answer a broader question: who is using AI, and how.

This may seem basic, but it is not a solved problem. As AI tools proliferate, usage often spreads beyond development teams to include product managers, analysts, and other business functions. In many cases, organizations lack a clear inventory of which tools are in use, what data is being shared, and where risks may be introduced.

FireTail focuses on providing that visibility.

The platform monitors both employee usage, such as interactions with tools like ChatGPT, and application-level usage, such as agents built on cloud AI services. It aggregates this activity into unified log streams, where it can detect potential issues like data leakage, policy violations, or anomalous behavior.

“The first use case for every customer is knowing who’s using what AI service,” FireTail founder Jeremy Snyder said. From there, organizations can define policies and, in some cases, enforce them, particularly at the endpoint or browser level.

This is a different kind of control point. It is less about enforcing behavior within the pipeline and more about establishing baseline visibility and governance across the organization. That distinction makes FireTail both broadly useful and somewhat peripheral to the core development life cycle. Visibility is a prerequisite for control, but enforcement requires additional measures.

Still, as AI adoption expands beyond engineering, that visibility may become a necessary first step, especially for organizations trying to understand their exposure before deciding how to manage it.

Raven: Enforcing trust where code runs

At the far end of the software life cycle, Raven represents a different kind of shift. Instead of focusing on code before it runs, Raven focuses on what happens when it does.

We described Raven last year as a runtime platform focused on prioritization and detection. This year, the emphasis has changed. The company is now pushing toward runtime prevention, with a more aggressive stance on what matters and what does not.

The core idea is straightforward. Static analysis produces large volumes of vulnerabilities, many of which are never exercised in production. At the same time, AI is reducing the time it takes to discover and exploit real weaknesses. As a result, the traditional model of scanning for known issues and prioritizing them based on CVEs is losing relevance.

Raven’s response is to focus on behavior at runtime, rather than signatures or known vulnerabilities. By observing how code executes inside the application, the platform attempts to identify and stop exploit activity directly, regardless of whether a vulnerability has been cataloged. As Raven co-founder and CEO Roi Abitboul put it, “We stop relying on CVEs and look at what the application is actually doing.”

That is a strong claim, but it reflects a broader trend.

The company uses a kernel-level approach to observe application behavior without injecting code or modifying the runtime environment, with the goal of minimizing performance impact. From that vantage point, it can identify anomalous behavior in libraries or functions and block execution in real time.

This is also where Raven diverges from much of the current AI narrative. While many vendors emphasize AI-driven detection, Raven argues that AI is too slow for real-time prevention and instead uses it selectively for analysis and prioritization tasks. The result is a model that treats runtime as the ultimate control point. If earlier stages fail or are bypassed, enforcement still happens where the code executes.

That position is not new in principle, but the context is. As AI accelerates both development and exploit generation, the gap between vulnerability discovery and exploitation continues to shrink. In that environment, runtime enforcement becomes less of a fallback and more of a primary defense.

Seezo: Securing what gets built, before code exists

One of the most dramatic shifts in information security is happening at the very start of the development life cycle.

In previous years, application security vendors focused on scanning code after it was written. Seezo is betting that, in an AI-driven world, that’s already too late. The company focuses on generating security requirements before code is written, shaping how both developers and AI agents build systems from the outset. The premise is simple: if AI is generating large volumes of code, then controlling what gets built becomes more important than analyzing what was built after the fact.

As Seezo co-founder and CEO Sandesh Mysore Anand put it, “The cost of generating code has gone to zero, while the cost of reviewing code is still very high.”

That imbalance is driving a quiet but important change. Instead of interrupting developers with scans and findings, Seezo inserts security into the requirements layer, the one place both humans and AI systems rely on to understand intent.

This is not just a shift-left story. It is a recognition that when AI agents are writing code, they are also reading instructions. If those instructions include security constraints, the resulting code improves before it ever hits a pipeline.

The trade-off is obvious. This approach depends on organizations adopting a more disciplined requirements process, something many teams have historically resisted. But as AI increases output, that discipline may become less optional.

TestifySec: Turning compliance into a continuous control

Promising to turn the development pipeline into a “live audit feed,” TestifySec is tackling a stubborn bottleneck: compliance as a gating function.

In traditional environments, proving that software meets regulatory or security requirements is slow, manual, and often disconnected from how code is actually built. That lag becomes a real problem when development accelerates, especially when AI agents are generating changes faster than teams can review them.

To answer this challenge, TestifySec moves compliance into the pipeline itself, using an evidence-based model. Instead of relying on documentation and manual audits, the platform maps code, test results, and artifacts directly to security controls and evaluates them continuously.

“Organizations can now write software fast, but we can’t ship it any faster because we can’t measure it,” TestifySec co-founder and CEO Cole Kennedy said. That measurement gap is what TestifySec is trying to close.

The platform uses AI agents to analyze what evidence should exist for a given control, then looks for that evidence across the codebase, pipeline outputs, and supporting artifacts. In practice, that means developers can get feedback on compliance before code is merged, rather than waiting for a downstream audit cycle.

This is a subtle but important shift. Compliance moves from being a post hoc validation step to a continuous signal inside CI/CD.

The challenge is trust. Automated compliance has been promised before, and organizations tend to be cautious about replacing human validation with machine-generated assessments. But as development speed increases, the alternative may be worse: a growing backlog of software that cannot be shipped because it cannot be certified.

Every direction at once

If there was a single takeaway from RSAC 2026, it is that the industry is no longer arguing about whether AI will change software development. It already has.

What is still being worked out is where security belongs when the boundaries between development, deployment, and execution no longer hold. The vendors highlighted here are not converging on a single answer. Instead, they are redefining control points across the entire life cycle, from requirements and toolchains to pipelines, runtime, and workflows.

Some of these approaches will prove more durable than others. Not every new layer will become a category, and not every claim will hold up under real-world pressure. But the direction is clear. As AI compresses the software development life cycle and accelerates both development and exploitation, security can no longer rely on isolated checkpoints.

Trust has to be enforced continuously, and in more places than before.

The challenge for organizations is not just adopting new tools, but deciding where those control points should reside in their environments. The answer will vary, but the underlying shift is the same: security is no longer a stage. It is part of the system itself.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top