The previous two articles in this series described a tooling landscape with limited reach into the runtime behaviour of deployed AI agents. That description requires a correction before the ownership question this article is organised around can be examined.
Since those articles were written, two market developments clarify where the earlier analysis was insufficiently precise. Cycode, an Application Security Posture Management platform, has built an AI Bill of Materials capability that continuously detects every AI tool operating across an organisation's software development lifecycle, commit history, rule files, MCP server configurations, model hookups across repositories. Its documentation describes an environment where 97% of organisations lack visibility into AI usage across their SDLC, and positions the AIBOM as the structural response: a continuously updated inventory of every AI component, from code assistants to MCP integrations.
Varonis, a data security company, acquired AllTrue.ai in February 2026 for a reported $150 million. AllTrue operates at the runtime layer, discovering AI systems in production environments, enforcing guardrails against unsafe or non-compliant behaviour, stress-testing for prompt injection vulnerabilities, and generating audit-ready reports aligned to AI governance frameworks.
A third development, published after this article was first drafted, reinforces the same correction from a different angle. On 20 February 2026, Anthropic launched Claude Code Security, a capability built into Claude Code that uses reasoning-based analysis to scan codebases for vulnerabilities and suggest patches for human review. Where earlier static analysis tools matched known patterns, Claude Code Security traces how data moves through an application and identifies flaws that rule-based tools miss. It found over 500 previously unknown high-severity vulnerabilities in production open-source codebases before launch. It operates at the pre-commit, developer-facing layer of the software development lifecycle.
All three developments are real, all address genuine problems, and the earlier articles were too broad in describing the tooling landscape as largely absent from this space. That was an error of precision, and it warrants acknowledgment rather than a quiet edit. The correction does not collapse the argument. It sharpens it: the security tooling gap identified in the earlier articles is being commercially addressed at pace. What remains open is a different and more specific gap, one that sits above the security layer entirely.
What These Tools Are Solving, And Where the Distinction Lies
Cycode is solving a software supply chain security problem: which AI tools are operating in your development environment, what instructions have been committed to your repositories, and which models are contributing to production codebases without formal approval. AllTrue and Varonis are solving a runtime security problem: can AI systems be observed in production, controlled in real time, and prevented from unsafe data access or malicious behaviour. The compliance layer AllTrue provides is audit reporting for framework alignment, demonstrating that guardrails exist and that risky behaviour is being blocked.
Neither tool is designed to answer the evidentiary question that financial regulatory frameworks are now establishing as the standard for AI deployments in regulated contexts. The FCA's model risk management principles (PS7/23) require documented model owners, articulated model limitations, and evidence of ongoing performance monitoring. The EU AI Act's requirements for high-risk systems (Articles 9 and 17) extend this further: technical documentation, human oversight mechanisms, and continuous monitoring obligations. The question these frameworks establish is not whether the AI system has been secured against misuse. The question is: when this AI agent made a consequential regulated decision, approved a credit application, generated a risk classification, produced a compliance filing, who in the product organisation was accountable for that decision, under what documented parameters was the system operating, how has its behaviour been monitored against those parameters since deployment, and what evidence exists to demonstrate that the gap between documented intent and runtime behaviour has been continuously assessed?
The Break-Glass Framing
A useful way to understand what accountability requires comes from security operations practice rather than the governance literature. Palo Alto's 2026 predictions describe AI agents as insider-threat equivalents and recommend treating agent permissions like production break-glass: tightly scoped, time-limited, with a named accountable owner who is logged for every invocation. The model assumes someone holds the register, that someone has named the conditions under which access is justified and reviews the log on an ongoing basis.
Applied to AI agents in regulated environments, the framing is revealing precisely because most organisations have not built the equivalent structure. The agent has been deployed. It has permissions. It is making decisions. The register, the named owner, the documented scope, the conditions of ongoing review, tends not to exist in a form that would be likely to satisfy a regulatory examination against those framework obligations.
Codrut Andrei, writing in The Product Security Brief, frames the underlying problem with precision: the difference between making inventory and audit trails a policy requirement and making them a product capability. Policy says these things must exist. Product capability ensures they actually do. That distinction maps directly onto the question this research is examining.
Who Owns It, and What Ownership Requires
The pattern that emerges from the governance literature and practitioner evidence is that AI agent governance accountability tends to accrue to the product function by default in regulated organisations. Not because the product manager has been explicitly assigned the accountability, but because no other function maintains a continuously updated view of what the agent is doing, why it was built to do it, and what acceptable behaviour looks like in the specific regulated context it has been deployed into. Where AI agents are procured from vendors, onboarding involves security, legal, and compliance review, but that scrutiny answers a procurement question, not an ongoing operational one. Risk, compliance, and security functions hold adjacent accountability, but they govern the environment, not the agent. In most organisations, the product function is the only role with continuous ownership of what the product does in production.
Default ownership is not the same as equipped ownership. For the accountability to be exercised rather than nominal, three structural conditions need to hold.
| Condition | What it requires | Current state |
|---|---|---|
| Decision authority at design time | PM documents acceptable behavioural parameters before deployment as an architectural commitment, not a policy sign-off | Typically a compliance review; PM and compliance operating on different assumptions |
| Ongoing monitoring mandate | Named owner reviews the gap between documented parameters and observed runtime behaviour on a continuous basis | Mandate unassigned or fragmented across functions without a clear owner |
| Evidentiary chain | Parameter documentation, monitoring data, and decision log linked traceably, not reconstructed after the fact | Assembled retrospectively from compliance documentation not designed to carry it |
The third condition is worth dwelling on. When a regulator asks for evidence that the AI system governing a financial decision was operating within its documented parameters at the time that decision was made, the answer requires a connected record. Building that chain is a product architecture decision. It cannot be retrospectively assembled from compliance documentation that was written for a different purpose.
Where the Research Goes Next
The ownership question examined here has a provisional answer: the product function carries the accountability by default, because no other function maintains a continuously updated view of what the agent is doing, why it was built to do it, and what acceptable behaviour looks like in the specific regulated context it has been deployed into. But default ownership without the three structural conditions described above is accountability in name without the means to exercise it.
The question the final article in this series examines is whether those structural conditions can be built into the product function's operating model, not as a governance overlay but as a change to how product decisions about AI agents are made and recorded from the outset. Whether the tooling landscape is developing to support that model, and whether the regulatory evidence standard emerging from frameworks currently in force in financial services is creating the forcing function to build it, are the questions the research is working toward.