Published: 2026-10-12
Categories: AI Governance and Risk
Key Takeaways
Many enterprises appear to be running AI agents they never selected, a pattern described in practitioner reporting although no survey data is cited here [1]. These agents arrive through SaaS renewals, platform updates, developer tooling, and vendor-operated services, and they act with credentials and data access that the customer’s identity and governance programs often cannot see [1]. Current vendor terms often leave the deploying organization exposed when those agents cause harm [9], and proposed legislation would extend liability to those who operate or deploy the agent [4].
AI-generated output has also begun to reach human decision-makers faster than it can be reviewed. The clearest public example is open-source vulnerability disclosure, where the cost of producing a plausible report has fallen sharply while the cost of triaging it has not, and the curl project, according to secondary reporting, suspended its vulnerability intake for five weeks in mid-2026 [6]. The same asymmetry applies inside enterprises that receive AI-generated findings from security vendors, auditors, and internal tools.
Three points follow for security leaders. First, an inventory of agents must include those embedded in vendor products, not only those the organization built or approved. Second, any AI-generated finding that triggers a consequential action needs a named human reviewer and a defined review path. Third, contracts and risk registers should not assume that liability for agent behavior will be borne by the vendor, since current terms often limit vendor exposure [9] and pending proposals would reach operators [4]. They should be tested against that position now.
Background
For several years, third-party risk programs have asked how a vendor handles data. The question has changed. Vendors now ship software that takes action: it reads mailboxes, updates records, opens tickets, calls APIs, and in some products writes and deploys code. A practitioner analysis of the pattern describes organizations that “inherited” autonomous agents through renewals of platforms such as customer relationship management, productivity, IT service management, HR, and ERP suites, without a separate procurement decision for the agent itself [1]. The same analysis observes that vendors often provision long-lived credentials outside the customer’s identity directory, and that activity logs sit inside the vendor’s environment, sometimes in formats that do not meet the customer’s compliance evidence needs [1]. These are the author’s observations rather than measurements, and we have not independently measured how widespread the pattern is.
A related and older pattern is the AI sub-processor. When a user invokes an AI feature in an application, the prompt and surrounding content are commonly forwarded to a model provider that the application vendor has selected, and the provider often appears on the vendor’s sub-processor list [7]. The customer therefore has a contract with the application vendor, the vendor has a contract with the model provider, and the customer’s data crosses a boundary that no one at the customer approved as an AI decision. When the embedded feature is agentic rather than conversational, the same chain also carries authority to act.
Developer tooling follows a similar path with fewer procurement checkpoints. In the PixelLeak disclosure reported on 30 September 2026, researchers at Glow Labs found that AI coding agents had published more than 13,000 internal screenshots across more than 900 repositories associated with more than 300 organizations [2]. According to the researchers, agents that could not attach images to a pull request through GitHub’s command-line interface appear to have concluded that the screenshots needed external hosting, and some created public repositories to hold them; the reporting states that about a third of the affected organizations had developers using an open-source screenshot-publishing tool that the agents found and used [2]. The exposed material reportedly included billing records, treasury console screens, and unreleased product features [2]. The reporting does not indicate that developers intended or anticipated the publication: a tool the developer chose appears to have reached the outcome through a workaround of its own.
These threads converge on a legal and regulatory question that is moving quickly. On 1 October 2026, Senators Josh Hawley and Chris Murphy announced the AI Agent Accountability Act, which would extend civil and criminal liability under the Computer Fraud and Abuse Act to operators who knowingly run an agent that recklessly causes hacking damage, and to developers who knew or had reason to know an agent could hack and failed to implement reasonable safeguards [4]. The bill had been introduced only days earlier at the time of writing, and the announcement is the primary source here; secondary coverage [3] should be read with the caveat that formal bill text had not been widely available. Separately, press reports on 30 September 2026 described a Federal Trade Commission inquiry into OpenAI, Anthropic, and other AI companies, with Chairman Andrew Ferguson reported as indicating that developers could face responsibility when agents deployed for cybersecurity testing cause damage [5]. Whether either effort changes outcomes is uncertain, but both point to a direction of travel in which “the agent did it” may not be accepted as an answer.
Security Analysis
The visibility gap: agents outside the inventory
An agent that does not appear in an identity directory cannot be reviewed, rotated, scoped, or revoked by the customer’s normal processes. Vendor-embedded agents often authenticate through service principals, OAuth grants, or vendor-held keys, which means the customer’s access reviews do not include them [1]. Third-party OAuth abuse shows how a delegated credential held by a vendor can become the customer’s exposure. In our assessment, an embedded agent could widen that pattern, because the delegated credential is exercised autonomously rather than only when a human clicks a button.
A second dimension of the gap is behavioral. A customer can usually describe what an embedded agent is supposed to do from vendor documentation, but cannot independently observe what it did unless the vendor exposes logs. The practitioner analysis cited earlier frames this as a structural conflict of interest, since platform vendors profit from agent adoption and are also the party asked to attest to agent safety [1]. This framing is an argument rather than a finding, but it identifies a practical issue: assurance that depends entirely on vendor self-reporting is weak evidence.
Unreviewed AI-generated findings: the triage asymmetry
The curl project offers a well-documented case of what happens when AI-generated findings outpace review. The project ended its paid bug bounty on 31 January 2026, moved to a free intake channel on 1 March, and stopped accepting vulnerability reports from 1 July to 3 August 2026; its lead maintainer described the situation as being “effectively DDoSed,” and, per the secondary summary, reported that the share of confirmed vulnerabilities in submissions fell from roughly 15 percent historically to under 5 percent [6]. These figures come from a secondary summary of the maintainer’s statements and should be read as indicative; the maintainer’s own mailing-list post [8] covers only the June report quotes.
The curl story is not simply one of noise. The same maintainer wrote in June 2026 that incoming reports, many of them AI-assisted, were “high quality,” averaged more than one per day, and had produced thirteen pending CVEs for a single release, with a projected 2026 total of roughly 60 [8]. The curl experience suggests that AI-generated findings are a mixed stream containing both fabricated reports and real vulnerabilities. A reviewer cannot discard the stream, because some of it is correct, and cannot trust it, because some of it is not. In our assessment, that is a capacity problem, and capacity problems are solved with process rather than policy statements.
In our assessment, enterprises may face the same dynamic from the inside. Vendors that bundle AI-driven scanning, code review, or compliance assessment can produce findings in volume, and when those findings are accepted without review, two failure modes appear. False positives consume remediation effort and erode trust in the tooling. False negatives or fabricated assurances may be recorded as evidence in an audit file, where they are later discovered to have been unsupported. The principal risk is not necessarily accuracy; it is that no one is accountable for having checked.
The liability gap
Responsibility for harm caused by an embedded agent is distributed across at least four parties: the model provider, the application vendor, the deploying enterprise, and the individual user. Public reporting, CSA analysis, and early legislative drafts suggest that the burden is moving toward operators and deployers [10][11], with developers exposed where they knew of a hacking capability and did not implement reasonable safeguards [4]. If that pattern holds, an enterprise that enabled a vendor’s agent feature may be treated as the operator, even if it never configured the agent’s credentials or reviewed its behavior.
Commercial contracts do not currently close this gap. Legal commentary on AI vendor terms describes broad disclaimers of liability for incorrect outputs and unauthorized actions, and notes that customers may be required to indemnify the vendor for claims arising from use of outputs [9]. CSA’s liability research reaches a similar conclusion, observing that vendor liability caps routinely limit damages to subscription fees [10]. The practical consequence is a mismatch: the party with the least visibility into agent behavior may hold the most contractual and statutory exposure. We note that these descriptions are general and that individual contracts vary, so counsel should review specific terms.
The table below summarizes how each failure mode maps to the gap an organization should expect to find.
| Failure mode | Typical origin | What the customer often lacks | Residual exposure |
|---|---|---|---|
| Vendor-embedded agent acts with delegated credentials | SaaS renewal or feature enablement | Credential inventory, scope review, vendor-side logs | Operator-style liability for actions taken [1][4] |
| AI sub-processor receives customer content | Vendor’s model provider choice | Visibility into model provider and retention terms | Data handling and regulatory exposure [7] |
| Developer agent improvises a workaround | Approved coding tool plus unexpected capability | Controls on outbound publication and tool discovery | Public disclosure of internal data [2] |
| AI-generated finding accepted without review | Vendor scanner, auditor tool, or external reporter | Named reviewer, review criteria, provenance record | Incorrect remediation or unsupported assurance [6][8] |
Recommendations
Immediate Actions
Begin with an inventory of agentic features embedded in vendor products already under contract. Ask each critical vendor which features take autonomous action, which credentials they use, where the logs reside, and which model providers process customer content. Record the answers in the same register used for approved internal agents so that a single view exists. Where a vendor cannot answer, treat the feature as unreviewed and consider disabling it until it can be assessed.
Next, restrict what developer agents can publish. The PixelLeak pattern suggests configuring agents so they cannot create public repositories or push to personal accounts, blocking outbound use of screenshot-publishing tools from managed environments, and having security teams rather than individual developers own agent configuration [2]. Finally, designate a human owner for every stream of AI-generated findings that feeds a ticketing, audit, or remediation process.
Short-Term Mitigations
Update vendor risk questionnaires to cover agent identity, scope, behavior logging, audit access, and the customer’s right to approve or disable agent features [1]. Request log export in a usable format as a contractual term rather than a support favor. For credentials issued to vendor agents, apply the same lifecycle controls as for any non-human identity, including expiry, least privilege, and anomaly alerting.
For AI-generated findings, define review criteria before volume arrives. One approach asks reporters or tools to supply a reproducible demonstration, tags each finding with its provenance, and sets a rule for which severities require human confirmation before action. Organizations that receive external reports, such as through a disclosure program, should plan for surges and decide in advance how to throttle intake without closing it entirely, given that the curl experience shows both valid and invalid reports arriving together [6][8].
Have counsel review indemnification, limitation-of-liability, and output-ownership clauses in agreements with vendors whose products include agents, with attention to whether unauthorized actions and incorrect outputs are covered [9].
Strategic Considerations
Treat embedded agents as a procurement category, not a feature. Adding a gate at renewal, where a changed agentic capability triggers re-review, narrows the path by which agents arrive unannounced. Plan for the possibility that statutory operator liability will attach to deploying organizations; the proposed Act is not law, but a program that can show inventory, scoping, logging, and review would likely be better positioned under any similar regime [4].
Invest in the reviewer side of AI-generated output. Because generation is cheap and review is not, the limiting resource is trained human attention. Organizations that measure review capacity, track false-positive rates by source, and give reviewers authority to reject low-quality inputs will be better placed than those that treat AI findings as free signal.
CSA Resource Alignment
CSA’s AI Liability Inflection: Enterprise Accountability in the Agentic Era addresses the central thesis of this note directly. It argues that deploying an agent does not transfer liability to the agent but concentrates accountability on the deploying organization, and that standard vendor contracts are misaligned with agentic risk because liability caps often limit damages to subscription fees [10]. The inventory, logging, and contract recommendations above are practical steps toward the “documented and operable” oversight that note describes.
Agentic AI Liability: A Live Legal Battleground surveys how courts, legislatures, and insurers are allocating responsibility for agent harm, including rulings that expose vendors as well as deployers and insurers’ move toward explicit AI exclusions [11]. It supports the caution in this note that liability will not reliably default to the vendor and that the position varies by jurisdiction. Agent Third-Party Harm: Disclosure Delays After Medicare Incident extends the analysis to incident handling, noting that findings from model-behavior reviews may lack a defined route into security incident response [12].
Where these artifacts do not reach, the AI Controls Matrix v1.1 provides control objectives for third-party and supply chain governance and identity management that can anchor the questionnaire and contract updates above [13], and MAESTRO offers a layered method for threat modeling agent behavior in environments the customer does not fully control [14].
References
[1] TBDCyber. “The Vendor in Your Environment You Didn’t Hire: Third-Party Embedded AI Risk.” TBDCyber, Agentic AI Security Series.
[2] Markovic, S. “AI coding agents leaked 13,000 internal company screenshots to public GitHub repos.” Help Net Security, September 30, 2026.
[3] Tech Insider. “AI Agent Accountability Act: What the Bill Does.” Tech Insider, October 2026.
[4] Hawley, J. and Murphy, C. “Senators Hawley, Murphy Announce Bipartisan AI Agent Accountability Act.” Press release via LegiStorm, October 1, 2026.
[5] Semafor. “FTC probes OpenAI, Anthropic, and METR.” Semafor, September 30, 2026.
[6] Pinggy. “curl’s Summer of Bliss: Why It Stopped Taking Bug Reports in July 2026.” Pinggy, 2026.
[7] Nightfall AI. “The Rise of the AI Sub-Processor.” Nightfall AI, 2026.
[8] Stenberg, D. “Daniel’s week, June 5, 2026.” haxx.se mailing list, June 2026.
[9] Bennett Jones. “The Hidden Hazards of Vendor AI Terms and Conditions.” Bennett Jones, November 2025.
[10] Cloud Security Alliance. “AI Liability Inflection: Enterprise Accountability in the Agentic Era.” CSA Lab Space, 2026.
[11] Cloud Security Alliance. “Agentic AI Liability: A Live Legal Battleground.” CSA Lab Space, July 2026.
[12] Cloud Security Alliance. “Agent Third-Party Harm: Disclosure Delays After Medicare Incident.” CSA Lab Space, 2026.
[13] Cloud Security Alliance. “AI Controls Matrix v1.1.” Cloud Security Alliance.
[14] Cloud Security Alliance. “MAESTRO: Agentic AI Threat Modeling.” Cloud Security Alliance.