✓ Human-authored analysis; AI used for formatting and proofreading.
The ThoughtWorks Technology Radar (April 2026) flagged something under "Caution" that describes one instance of a problem we encountered from a completely different direction — implementing S3 bucket takeover findings from HackerOne triage work: When the spreadsheet that quietly runs the business evolves into customized agentic workflows that lack governance, it introduces significant security risks and a proliferation of competing solutions to similar problems.
The problem ThoughtWorks describes is about the lifecycle of cloud resources.
That lifecycle has been producing ungovernered risk long before AI workflow tools existed.
When we triaged S3 bucket takeover reports on HackerOne, the pattern was clear: a team creates a bucket, uses it, stops using it, deletes it — but the DNS record, the CloudFront distribution, or the application code still references the old bucket name.
An attacker creates a new bucket with the same name and takes over the traffic.
The resource was deleted.
The references were not deleted.
The lifecycle wasn't governed.
This is the same structural problem at every phase: AI workflow tools accelerate the CREATE phase.
But the lifecycle problem exists at every phase.
It existed before AI tools made it faster.
ThoughtWorks is seeing the acceleration.
The underlying problem is the ungoverned lifecycle.
The spreadsheet that quietly runs the business.
Every organization has one.
The revenue model nobody documented.
The customer onboarding flow that lives in someone's head and a Google Sheet.
The compliance checklist that's a macro.
Now that spreadsheet is becoming an AI workflow.
Claude Cowork, GPT wrappers, no-code platforms with OpenAI integrations — non-coders are building systems that provision cloud resources, call APIs, move data, and make decisions.
The barrier to building dropped to zero.
The barrier to governing what was built didn't drop at all.
The resource lifecycle problem The S3 bucket takeover is just one example.
The pattern repeats at every lifecycle phase: A team creates an S3 bucket for a project.
The project ships.
Six months later, the team reorganizes.
The bucket stays.
The IAM policies stay.
Nobody audits a resource that works.
A year later, the project is decommissioned.
Someone deletes the application code.
Nobody deletes the bucket.
Nobody removes the DNS record that points to it.
An attacker registers the bucket name and captures the traffic.
AI workflow tools make this faster.
A marketing manager builds an AI workflow that provisions a bucket, an API gateway, and a Lambda function.
The workflow works for two weeks.
The manager moves on to the next experiment.
The resources stay — untagged, unowned, with whatever permissions the AI agent assigned.
But the lifecycle problem isn't caused by AI tools.
It's caused by the absence of a governance mechanism that operates across the full lifecycle — create, use, modify, abandon, delete and catches the structural violations at each transition.
AI tools accelerate the creation phase.
The lifecycle was ungoverned at every phase before AI existed.
This means the problem is larger than what the Tech Radar identified.
AI-accelerated shadow IT is one phase of a five-phase governance gap.
Ghost references from deleted resources, orphaned infrastructure from reorganized teams, configuration drift from accumulated changes, privilege escalation from composed policies — these exist in every cloud environment, regardless of whether AI tools were used to create the resources.
Every organization has resources that were created by engineers who left, modified by scripts that were forgotten, and referenced by infrastructure that outlived its purpose.
The ThoughtWorks finding is the visible tip.
The lifecycle governance gap is the iceberg.
A solution that addresses the full lifecycle solves a problem every cloud environment has today.
How this problem was identified: a 5-month arc The lifecycle governance gap didn't surface from reading the ThoughtWorks Radar.
It evolved through five months of work from TRIZ contradiction analysis through real incident triage to architectural design: Month 1 — Symptom.
TRIZ contradiction analysis of cloud security identified shadow IT as the consequence of overly restrictive authentication.
When security friction is too high, users route around controls.
The contradiction: stronger authentication increases security but pushes users to create ungoverned workarounds.
Shadow IT is the escape valve.
Month 2 — Architectural gap.
If you can't observe it, you can't include it in a safety plane.
Shadow IT became the canonical example of unobservable infrastructure.
The resource that exists but isn't part of any governance system.
The focus shifted from "write better rules" to "capture what exists." Month 3 — Concrete evidence.
The S3 bucket takeover case study from HackerOne triage named the real-world pattern: abandoned developer test projects in a folder — shadow IT that accumulated over time.
Dangling DNS references to deleted buckets.
Attacker registers the bucket name, captures the traffic.
Shadow IT moved from abstraction to forensic finding with a dollar-cost breach attached.
Month 4 — ThoughtWorks confirmation.
The Tech Radar listed "AI-accelerated shadow IT" under Caution.
This confirmed the pattern.
Agents create infrastructure faster than humans observe it, collapsing the shadow IT timeline from years to hours.
The acceleration was new.
The underlying lifecycle problem was already documented.
Month 5 — Solution shipped.
The safety-level model defines Level 1 as "default drift" — the shadow IT floor.
The customer pitch: "your effective security level is your weakest workflow, not your headline workflow." The solution: uniform gate enforcement across every workflow.
One CI gate.
Every PR.
No shadow corners left behind.
The solution — runs deterministically against any configuration snapshot the CI can put in front of it.
It was designed and built before the ThoughtWorks Radar confirmed the problem.
The Radar validated the market signal.
The architectural work was already done.
ThoughtWorks recommendations are necessary but insufficient The Tech Radar recommends four measures:
1.
Facilitate experimentation within controlled environments.
Correct — sandboxes are necessary.
But who writes the sandbox rules?
If the sandbox is a separate AWS account with no guardrails, the shadow IT just moved to a different account.
The sandbox needs the same governance as production.
Otherwise it's not a sandbox — it's an ungoverned playground.
2.
Appropriately instrumented internal sandboxes where usage can be tracked.
Correct — tracking is necessary.
But tracking is observation (Stage 2 on the control maturity curve).
It tells you what happened.
It doesn't prevent anything.
By the time you observe the public bucket with PII, the data is already exposed.
3.
A shared catalogue of existing workflows helps teams discover what's already been built.
Correct — discovery prevents duplication.
But discovery doesn't prevent misconfiguration.
Knowing that three teams built similar workflows doesn't tell you whether any of them configured their resources safely.
4.
Workflows that gain traction can then signal where to invest in more robust, production-grade applications.
Correct — traction signals investment priority.
But the risk lives in the gap between "gained traction" and "rebuilt production-grade".
The workflow is already running.
Data is already flowing.
Resources are already provisioned.
Waiting for traction before governing is waiting for the breach before locking the door.
Each recommendation is a necessary practice.
None is a structural mechanism that prevents misconfigured resources from reaching production.
All four operate at Stage 2-3: observe, track, discover, prioritize.
None operates at Stage 4: verify before deployment, block violations mechanically.
The structural fix The gap ThoughtWorks