A marketing team at Thoughtworks was scaling a video-assembly prototype - built with Gemini, Replit AI and Claude across three separate tools - into something 10,000 employees would use. Twice, the AI agent recommended a change with serious security consequences, and twice a person had to notice and push back.
The first time, the agent suggested making a cloud storage bucket public, or setting file sharing to "anyone with the link." When challenged on this, according to the team's account, it justified the choice by saying that's what every company does. Only a firm rejection produced a secure alternative. Had it shipped, the team says, it could have exposed unreleased brand assets and audience data.
The second time, a service account was given the Access Token Creator role - far more access than the task needed, and enough that a compromised account could have moved laterally across the whole cloud workspace. The team caught it before the code ran.
Thoughtworks, whose engineers wrote up the incident on Martin Fowler's site, draw one conclusion from both: AI agents tend to suggest the path of least resistance, and that path is often not the secure one. Human judgement caught these two. It shouldn't have to be the only thing standing between a prototype and a public data leak. What follows is what their account establishes about the coverage a security context file and a secure-by-default starting point need, and the operating principles behind them - not the file or the template itself, which the article we're drawing on does not publish, and which we have not reconstructed here.
Telling the agent isn't the same as stopping it
After the two incidents, the team's engineering colleagues gave them a piece of feedback worth sitting with: telling an AI agent to "be safe" is a suggestion, not a control. A user rephrasing a request, or simply pushing back once, can make a prompted restriction evaporate. One piece of internal engineering guidance they quote puts it plainly: if something absolutely must not happen, it has to be codified as a non-negotiable rule somewhere in the development lifecycle, not left as an instruction the model is trusted to keep honouring.
They draw the comparison to test coverage: prompting for test-driven development is not the same as enforcing a coverage threshold in the build tool. One is a request. The other is a gate.
That distinction shapes everything else in their account, and it's worth separating from a second, weaker one the article makes: the team also cites external 2026 research - on breach rates linked to AI-generated code, and on the share of AI-generated code with confirmed vulnerabilities - as evidence that what happened to them isn't unusual. That research comes from third parties (AppSec Santa, Black Duck, Aikido Security and others, per the article), not from the Thoughtworks team's own measurement, so it's best read as supporting context for their argument rather than an independently verified number to repeat elsewhere.
The security context file
The team's first concrete response was a security context file: a document of technical security rules loaded into every AI coding session before any code is written, so the agent has the rules as context from the first prompt rather than being told about them mid-conversation.
What sets it apart from a one-off prompt, in their description, is operational discipline rather than content: it's versioned, loaded by default, reviewed, and - this is the part that matters - paired with automated checks rather than left to stand on its own. The team is explicit that the file is an inferential guide (it shapes what the agent is likely to produce) and that this has to be backed by computational, deterministic checks in the pipeline that can actually fail a build. The clearest worked example is the harness engineering gates themselves: scanning and validation that must pass before deployment, rather than resting on the prompt alone. The article frames this as a general pairing running through the whole file - guidance shapes what the agent is likely to produce, and pipeline checks catch what the guidance misses - not a claim that every one of the five categories has its own dedicated automated check standing behind it.
The team names five categories the file covers: zero trust and least-privilege defaults on every service account and storage resource; secrets management, so the agent routes credentials to environment variables or a secrets manager rather than generating or storing them in code; harness engineering gates - scanning and validation that must pass before deployment, rather than resting on the prompt alone; supply chain integrity; and AI accountability. The article sets out what the first three should look like in practice in the most detail. Supply chain integrity and AI accountability get the same treatment in miniature - each still has its own account of what good looks like - but in fewer words, so what's transferable there is thinner than for the first three without being just a category name.
Secure-by-default starting points
A context file governs what an agent is told before it writes anything. Their longer-term proposals address a different point in the process: what a project starts from. Their account frames this as making the secure path the easy path - if the default option offered to a citizen builder is already the safe one, there's less for a prompt or a review to catch later.
In practice this means templates that pre-configure the things their two incidents turned on: authentication patterns, private-by-default storage, secrets handling, and dependency scanning built in from the start, rather than added after a prototype is already running. A builder starting from such a template isn't relying on the agent to choose the secure option each time - the secure configuration is the one the project inherits from the start, not a guarantee that removes the need for review.
They propose building a shared starter harness jointly across business functions, engineering and security, rather than something engineering hands down or each team assembles for itself. Their reasoning is that without a shared starting point, every team building with AI ends up rediscovering the same mistakes - the public bucket, the over-permissioned service account - independently, rather than inheriting a baseline that already accounts for them.
The article doesn't publish the template itself or its exact contents, and neither do we here - what's transferable is the shape of the idea: decide what "secure by default" means for your organisation's most common building blocks, encode it in the starting point every project inherits, and build it as a shared artefact rather than leaving each team to work it out under time pressure.
Knowing what changed overnight
The third practice is the cheapest to set up and the easiest to skip: a daily digest of what has just become dangerous. The team's version monitors the languages their teams write in, the cloud platforms they deploy to, the AI coding tools themselves, and the CVE database generally, and delivers new CVEs, platform advisories and security bulletins once a day. The stated goal is narrow and worth stating: to hear about a vulnerability on the day it is disclosed rather than weeks later.
The reason for watching the coding tools specifically is their own argument: Sonar's 2026 State of Code Developer Survey, based on responses from more than 1,100 professional developers, found that those developers reported AI generating or assisting around 42% of the code they personally commit, and the team reasons that the tools accelerating development are also the ones most likely to turn up in new disclosures.
Their broader point about both this and the context file is that neither needs an engineering background to adopt. One is a policy document structured so a model will read it; the other is an automated search. What they have in common is that passive awareness stops being enough once code is arriving at the speed an agent produces it.
Two habits that don't need the context file or the harness
Before any of that infrastructure exists, the team suggests habits any builder can start immediately. Neither depends on the security context file or the starter harness being built first - though that's not quite the same as needing no tooling: asking the agent to attack its own work only works if you already have an AI coding tool to put the prompt to, in a way that questioning a permission does not.
- Question every permission the agent suggests. If it recommends making something public, or assigning a broad role "to keep things simple," stop and ask why. Their own experience is the evidence: both incidents were exactly this kind of suggestion, and in both cases it was a person asking that stopped it.
- Ask the agent to attack its own work. Prompting the AI to roleplay as an attacker and pen-test what it just built is, in the team's account, a technique that consistently surfaces the vulnerabilities that forward-looking prompts miss - particularly around permissions and data exposure.
Neither replaces the context file or the starter harness. They're what you can do on the next prototype while those are still being built.
The principles behind the practices
Strip away the specifics of buckets and tokens and the account establishes a small number of principles that carry to situations Thoughtworks never encountered:
- An instruction given to a model is a request, not a control. It can be rephrased around, argued past, or simply ignored under pressure, however clearly it's worded.
- Anything that absolutely must not happen has to be codified as a non-negotiable rule somewhere in the development lifecycle, not left as an instruction the model is trusted to keep honouring - with deterministic checks as the complementary control, backing that rule up with something that can actually fail a build.
- The secure option should be the one a project starts from, not the one a review has to catch. A default that is already safe removes a whole category of mistake before anyone has to notice it.
- None of this removes a person's accountability for consequential security decisions. Guidance shapes what an agent is likely to produce; deterministic checks catch what guidance misses; a person still decides whether the result is safe enough to ship.
What this doesn't settle
None of this removes the need for judgement about when a piece of software is risky enough to need more than a context file and a template - a payments flow or anything handling regulated data is a different conversation from an internal prototype. The site's piece on when AI-generated software needs professional review covers that decision in more detail. What this account gives you is more specific than "get it reviewed": what a security context file needs to cover, what a secure-by-default starting point should pre-configure, and how model guidance, deterministic enforcement, automated checks and human accountability fit together. It does not give you the file or the template themselves - the article doesn't publish them, and we haven't built one to fill the gap.