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.
