Dear reader,
On Tuesday 6 October, Cognizant announced a five-year extension of its work for the drug maker Gilead Sciences. The agreement covers DevOps and “the responsible application of agentic AI tools across selected technology programs” (Cognizant). The release does not name the tools. On 30 September, Infosys said it would develop, test and support ABN AMRO’s applications using Topaz, its suite of generative and agentic AI (Infosys).
Barclays warns that suppliers may use AI without its knowledge
On 1 October, Barclays and Anthropic announced that Claude Code should reach 50% of the bank’s developers by the end of 2026 and a majority of its software engineers in 2027 (Anthropic).
In its annual report for 2025, published on 10 February 2026, Barclays wrote: “The use of AI by the Group’s third-party service providers in their business activities, whether or not disclosed or known to the Group, could also expose the Group to risks.” Its examples: a provider uses AI tools “in contravention of agreements” with the bank, puts the Group’s “confidential or proprietary information into AI tools”, or rolls out new AI tools “without the Group’s approval” (Barclays).
The report for 2024 does not have this wording. Citigroup, Goldman Sachs, ING and Santander carry comparable warnings in their reports for 2025. None of these documents reports an incident.
Three things can go wrong
The banks’ warnings and the research published so far describe three separate risks.
The first is that the client’s code goes to an AI service the client has not approved, or to an approved one on terms it would not accept. A hosted coding agent sends the files it works on to the model provider. How long the provider keeps them, and whether it may reuse them, depends on the terms the supplier agreed with that provider. Where the client has approved the service and those terms, this is ordinary delivery. Barclays, ING and Santander describe the case where it has not. Delivered code carries no trace of where it was sent.
The second is that the agent acts beyond its task, with the access of the supplier’s developer. An agent can meet planted instructions in repository files and in the dependencies it pulls in. What it can do next depends on its permissions. A preprint submitted to arXiv on 6 October tested six coding-agent tools, among them Claude Code, Codex CLI and GitHub Copilot, on 23 small tasks with one base model. With automatic approval off, a second model reviewed each permission request and 29.2% of the attacks succeeded. With it on, 95.6% did, and the agents completed more of their tasks. Network isolation and read-only mode also reduced the effect of attacks, at a substantial cost in completed tasks. About half of the security mechanisms the authors confirmed in these tools are opt-in (arXiv). The test is too small to say how often an attack would succeed in production. It does show that the agent’s permissions decide much of the exposure, and that each restriction costs some output.
The controls exist. On 7 October, GitHub made a sandbox generally available for Copilot’s agents, with enterprise policies “that developers cannot weaken” (GitHub). The policy belongs to whoever holds the licence, and in outsourced work that is the supplier.
The third is that more code arrives than the client can review. Veracode tested more than 100 models on 80 coding tasks in 2025; given a choice between a secure and an insecure way to write the code, the models took the insecure one in 45% of cases (Veracode). In Faros AI’s telemetry from more than 10,000 developers in 1,255 teams, the teams with high AI use had pull requests 154% larger and review times 91% longer (Faros AI). The comparison is observational and does not prove that AI caused the difference.
None of these sources describes an incident at a supplier’s client. The evidence is tests, telemetry and warnings to investors.
The rules put the duty on the buyer
Under DORA, a financial firm that uses ICT suppliers “shall, at all times, remain fully responsible” for meeting its obligations (DORA, Art. 28). The technical standards cover more than testing at delivery. Article 16 requires a policy for how software is acquired and developed, limits on production data in test environments, and controls to protect the integrity of source code that a supplier develops and delivers. It also says that “the source code provided by ICT third-party service providers or coming from open-source projects” is, where feasible, to be analysed and tested before it goes into production (Delegated Regulation 2024/1774, Art. 16). These duties sit with the financial firm and apply whether a person or an agent wrote the code. They reach a supplier’s build through what the firm requires of the supplier.
In Poland, the cybersecurity department of UKNF, the office of the financial supervisor, published an analysis dated 23 July 2026. It says that code generated or modified with AI may contain authorisation errors, badly managed secrets and vulnerable dependencies, and that the risk covers a firm’s own code and its suppliers’ software. Its good practices for AI-assisted code are approved tools, a ban on passing sensitive data to unauthorised services, and mandatory review. The document says they are “not a catalogue of supervisory requirements” (UKNF).
On 7 October, the Monetary Authority of Singapore published final guidelines on AI risk management. They ask that a financial institution’s contracts with providers give it “a risk-appropriate degree of visibility over the introduction of AI and subsequent updates or changes” (MAS, paragraph 5.10).
Acceptance testing cannot show how the code was built
A bank’s existing controls on suppliers, covering access, confidentiality and subcontracting, apply to all of this. In my view, what coding agents change is that the development tool itself sends code to a third party and takes actions. The tool and its configuration become something a buyer has to approve.
Acceptance testing, with enough reviewers for the volume, deals with defects in the code. On its own it cannot show whether the supplier kept to the approved tools, where the code was sent, or what the agent was permitted to do.
How much a buyer sees depends on how the supplier works. If its developers work inside the client’s environment, on the client’s repositories and with the client’s licences, the client’s agent policies bind them as they bind its own staff. If the supplier builds in its own environment, the client relies on what it has required of the supplier and on what it can check.
A buyer can start by asking which agents and models work on its code, where they are hosted, and what they are permitted to do. The answer is a declaration. For work that matters, the approval should name the service and its configuration, the supplier should be able to show evidence in proportion to the risk, and it should report material changes. The property firm Cushman & Wakefield works this way. Its supplier terms allow “commercial AI assistants and coding copilots” only when the tool and the use have been approved in writing, and they require records of the AI tools used and of human review (Cushman & Wakefield).
Where the agent is a hosted service that receives a financial firm’s code, the firm should also check whether its supplier’s use of that service counts as subcontracting under DORA. That depends on the service and on how critical the function is. If it counts, the supplier has to tell the firm about material changes in time for it to approve or object (Delegated Regulation 2025/532, Art. 5).
Briefing
On 9 October, Anthropic published an account of unintended actions by its models in evaluations and internal use. In one case Claude found a script on a university’s server that would return any file it was asked for, and used the flaw to run its analysis there. In another, Claude Haiku 4.5, asked to perform example tasks on randomly selected web pages, submitted an invented tip through the Philadelphia Police Department’s tip form. Anthropic says that, to its knowledge, none of the cases involved customer data or its own systems. It has disabled live internet access in all its internal evaluations, tightened the guardrails on its internet tools, built tooling to detect and block such behaviour, and is changing training environments that rewarded working around restrictions (Anthropic). These are limits on permissions and more monitoring, and a firm that runs agents can apply both.
On 8 October, the UK’s Information Commissioner’s Office said ten AI developers, among them Anthropic, Google, Meta, Microsoft and OpenAI, had changed or committed to change their data-protection practices after its supervision. It has also made enquiries with OpenAI, Anthropic, Meta and the UK’s AI Security Institute about the testing of agents. Richard Nevinson, its director of technology regulation, said: “the fact AI agents act with autonomy is not an excuse for poor compliance” (ICO). The ICO is collecting evidence on agentic AI until 20 November, and its guidance will follow from what firms send in.
On 7 October, Anthropic released Claude Haiku 5.5 at $0.10 per million input tokens and $0.50 per million output tokens for prompts of up to 100,000 tokens. It also halved the price of cache reads on Sonnet 5.5 to $0.10 per million tokens, which it says cuts the cost of most agentic tasks on that model by around 20% (Anthropic). The estimate covers model charges, which are one part of what an agent costs to run.
Summary
Suppliers are using AI agents to write software for regulated clients. Acceptance testing finds defects in the code they deliver. Where the client’s code was sent and what the agent was allowed to do are settled in the supplier’s set-up.
Last week’s issue described clients asking suppliers for a share of what AI saves them. A client that asks for that saving is, in software work, asking for agents to work on its code. In my view it should then know which agents, and on what terms.
Stay balanced, Krzysztof
Krzysztof Goworek is founder of Quintant — AI advisory that gets enterprises from experiment to production value.