✓ 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:
Create → Resource provisioned with AI-generated defaults. Nobody reviews the policy.
Use → Resource accumulates dependencies. Other resources reference it.
Modify → Configuration drifts from original intent. Nobody tracks the drift.
Abandon → Team moves on. Resource remains. No owner. No review. Full permissions.
Delete → Resource removed. References survive. Ghost references. Undefined behavior.
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 samples/ 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 — stave apply 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 identifies — governance for AI-accelerated workflows is one instance of the broader lifecycle governance problem. The structural fix requires three properties:
1. Operates at every lifecycle phase, not just creation. The governance mechanism must check resources when they're created (catching bad defaults), while they're in use (catching drift), when they're modified (catching regressions), and after they're abandoned (catching orphans and ghost references). A CI gate at creation time is necessary but insufficient — most lifecycle violations happen after creation.
2. Mechanical, not manual. No security team can review every resource across every lifecycle phase. The governance must be automated. Evaluate every configuration snapshot against every declared safety property, mechanically, on every check.
3. Structural detection without intent. Resources created by AI workflows, abandoned by reorganized teams, and inherited from legacy infrastructure don't have tags, owners or intent declarations. The governance must detect violations from the configuration structure alone — attack paths, ghost references, privilege escalation, orphaned permissions without any metadata from the builder.
How this works in practice
An AI workflow provisions cloud resources. The resources have configuration state captured by the cloud provider's APIs. A collector takes a snapshot of that state. A JSON file representing every resource, policy, relationship at the moment of capture.
A specification gate evaluates the snapshot against a catalog of safety invariants:
Invariant: No S3 bucket in any account may have public access
without an explicit exemption in the governance catalog.
Invariant: No IAM role may allow privilege escalation through
PassRole, PutRolePolicy, or AttachRolePolicy without
conditions (MFA, source IP, org boundary).
Invariant: No resource may reference a deleted dependency
(ghost reference — security group pointing to
deleted VPC, role trusting deleted account).
Invariant: No attack path may exist from any public principal
to any internal resource through any chain of role
assumptions and policy attachments.
Each invariant is checked mechanically. The marketing manager's AI-provisioned bucket either satisfies the invariants or it doesn't. If it doesn't, the violation is flagged with the specific invariant that failed, the specific resource that violated it, and the specific evidence from the configuration state.
No security knowledge required from the builder. The builder doesn't know the invariants exist. The invariants check the output, not the input. The builder provisions resources. The specification gate verifies them.
The detection classes that matter most for lifecycle governance
Each lifecycle phase produces a specific class of structural violation:
Ghost references (DELETE phase). A resource is deleted, but other resources still reference it — a DNS record pointing to a deleted S3 bucket, a security group referencing a deleted VPC, a role trusting an account that was decommissioned. This is the S3 bucket takeover pattern from HackerOne triage: the resource is gone, the references survive, the attacker registers the name and captures the traffic. Detectable by cross-referencing every resource identifier in the snapshot.
Orphaned resources (ABANDON phase). A team moves on. Resources remain — provisioned, untagged, unowned, with whatever permissions were assigned at creation. They're attack surface with no owner and no review cycle. Detectable from the snapshot: resources with no tags, no recent access, and broad permissions.
Privilege escalation paths (CREATE + MODIFY phases). AI agents generate policies that individually make sense but compose into escalation chains. Role A can assume Role B. Role B can pass Role C to Lambda. Role C has admin access. No individual policy is wrong. The chain is exploitable. Detectable by computing transitive closure over the permission graph.
Public access by default (CREATE phase). AI agents generating resource configurations use permissive defaults. Policies mathematically equivalent to Principal: * through condition logic that covers the entire input domain. The text doesn't contain the wildcard. The math does. Detectable by formal verification — SMT solver checks if the conditions form a tautology.
No conditions on sensitive actions (CREATE phase). AI-generated IAM policies rarely include conditions (MFA, source IP, org boundary). The builder doesn't know conditions exist. Sensitive actions are permitted without identity verification beyond initial authentication. Detectable from the statement structure — Allow + sensitive action prefix + empty condition block.
Configuration drift (MODIFY phase). A resource was configured correctly at creation. Changes accumulated over months — a new policy attachment, a modified security group rule, a relaxed encryption setting. Each individual change was small. The cumulative state violates the original safety properties. Detectable by evaluating the current snapshot against invariants — the invariants haven't changed, the configuration has changed.
Every one of these is detectable from the configuration structure alone. No tags, intent declarations or security knowledge from the builder. The snapshot is sufficient evidence.
The governance model across the lifecycle
Resource is created (by AI workflow, IaC, console, script — any channel)
→ Resource exists in cloud provider APIs
→ Collector snapshots resource state periodically
→ Specification gate evaluates snapshot at every phase:
CREATE: Are defaults safe? Any public access? Missing conditions?
USE: Has drift occurred? Do references still resolve?
MODIFY: Does the change violate existing invariants?
ABANDON: Is the resource unowned? Untagged? Unused?
DELETE: Do ghost references survive? Dangling dependencies?
→ Violations flagged with specific invariant + evidence
→ Clean resources pass without human review
→ Security team reviews INVARIANTS (small, stable)
→ Not ALERTS (large, noisy, lifecycle-spanning)
This addresses each ThoughtWorks recommendation and fills the structural gap:
Sandboxes: The specification gate runs on sandbox accounts AND production accounts. Same invariants. Same evaluation. The sandbox isn't ungoverned. It's governed by the same safety properties, automatically.
Tracking: The specification gate doesn't just track what happened — it blocks what shouldn't happen. Stage 4 (verify before deployment), not Stage 2 (observe after deployment).
Shared catalogue: The invariant catalog is the shared catalogue of governance rules. 3,000+ safety properties across 74 cloud service domains. Every team uses the same catalog. Every non-coder's resources are checked against the same invariants.
Traction signals: The specification gate's coverage metrics (readiness, gaps) report which resources are governed and which aren't. Resources provisioned by shadow IT workflows that aren't covered by the observation contract are flagged as coverage gaps — visible, tracked, reportable. The gap between experimented and production-grade is measured, not assumed.
The limitation
The specification gate evaluates what's observable through the cloud provider's APIs at the moment of capture. Resources provisioned through channels the APIs don't fully expose, resources in accounts the collector doesn't access, and ephemeral resources that were deleted before the snapshot — these are outside the observation window.
Findings are lower bounds, not exhaustive inventories. "We found 3 attack paths" means at least 3 exist. It doesn't mean only 3 exist.
The tool states this in every output: "Analysis covers API-observable state at capture time. Resources not visible to the collector are not evaluated." Transparency about coverage limits is as important as the findings themselves.
The bottom line
ThoughtWorks correctly identified that AI-accelerated shadow IT is a governance crisis. Their recommendations — sandboxes, tracking, shared catalogs, traction signals are necessary practices. But practices are Stage 2-3: observe, track, discover, prioritize.
The structural fix is deeper than a Stage 4 CI gate. It's uniform gate enforcement that eliminates the distinction between core and shadow workflows.
Today, organizations have two tiers: the reviewed core (Level 5 — formal review, compliance controls, documented architecture) and the shadow corner (Level 1 — default drift, no review, no governance). The team's effective security level is the weakest workflow, not the headline workflow. The breach happens in the shadow corner, not the reviewed core.
The specification gate makes this distinction disappear. Every configuration snapshot — whether it came from a senior engineer's Terraform, a marketing manager's AI workflow, or a forgotten test project from 2019 — goes through the same evaluation against the same 3,000+ safety invariants. There's no opt-out tier. No "this is just a test project" exemption. No shadow corners left behind.
The team's effective level becomes the gate's enforcement level — uniform across all workflows, all resources, all lifecycle phases. Because the gate's enforcement is uniform across all of them.
The governance mechanism the Tech Radar is looking for isn't a process improvement. It's a structural change: one gate, every snapshot, no exceptions. The lifecycle governance gap — from creation through abandonment through deletion — closed by a mechanism that doesn't know or care who created the resource, what tool they used, or whether they intended it to be temporary.
The structural violations described in this article are detected by Stave — an open-source cloud security reasoning engine that evaluates configuration snapshots against 3,000+ safety invariants. Apache 2.0. Air-gapped. No cloud credentials required.
Top comments (0)