The warning isn't only about better security tools
On August 27, 2026, OpenAI published a call for collective action on cyber defense, co-signed by Anthropic, Google, Microsoft, AWS, Cisco, Cloudflare, CrowdStrike, IBM, Oracle and more than 110 other technology, security, and financial organizations. The letter is blunt about timing: “We have a limited window” before AI-enabled attacks become far more widespread and sophisticated.
What is easy to miss is that the letter does not stop at detection and response. It names the underlying exposure directly — “longstanding bugs, excessive permissions, misconfigurations, insecure and unpatched software, weak authentication and technical debt in legacy systems” — and it calls on organizations to “fix the highest-risk weaknesses, verify results without disrupting essential services and raise the security bar for what you buy, build and deploy, including AI-generated code.”
Read together, that is not only a cybersecurity program. For a large share of enterprises, fixing that list requires changing the systems, not just patching them. For many organizations, it is a modernization program with a security mandate attached.
Much of today's cyber debt is architectural debt
Not every vulnerability on that list can be patched in place. A meaningful subset requires changing the system's architecture: obsolete authentication schemes, unsupported dependencies that carry excessive privilege, direct database access that should have become a controlled API years ago, monoliths whose service boundaries were never drawn, deprecated platforms, and trust assumptions nobody wrote down.
None of that is patchable with a version bump. It requires deciding what the system should look like, then rebuilding toward that decision — which is exactly what a migration is.
AI changes the economics of migration
This is where the timing of the letter matters. AI coding agents can now read legacy code, recover undocumented behavior, generate migration specifications, transform implementations, write tests, and execute large numbers of changes with very little human involvement per change. Thoughtworks' own account of AI-assisted legacy migration describes the front half of this pattern: extracting undocumented business logic from a legacy codebase into structured specifications, structured enough to feed directly into code generation.
That capability is genuinely useful. It is also the reason “AI makes migration faster” is no longer an interesting claim on its own. The open question is different: what happens when migration execution becomes faster than architectural review?
Migration has a two-sided drift problem
An AI-driven migration can fail in two directions at once, and both are easy for a fast-moving agent to produce without anyone noticing until much later.
Legacy preservation failure
The agent carries forward something the migration was supposed to eliminate: excessive permissions, an insecure communication pattern, an obsolete library, a workaround nobody remembers the reason for, coupling that was never supposed to survive the rewrite.
Target architecture failure
The agent understands what the old system did, but implements the replacement incorrectly: the wrong persistence technology, a bypassed service boundary, a new unauthorized dependency, an incorrect trust boundary, business logic duplicated instead of consolidated.
Both failure modes look identical from the outside — tests pass, the migration “completes” — and both are precisely what the collective cyber-defense letter is asking organizations to eliminate, not reintroduce at higher speed.
The missing artifact is the executable target architecture
Traditional migration reasoning goes: current state → migration plan → target architecture → implementation. Agentic migration needs one more step in the middle: current state → recover intent → define target decisions → make those decisions machine-consumable → agent changes → verify the result.
A hundred-page target-architecture document is not a guardrail. Neither is pasting every ADR into a prompt. An agent moving at migration speed needs to know, for each proposed change: which decision applies, to what scope, whether it is guidance or enforceable, and what a violation of it looks like — before the change lands, not after.
The migration control loop — enforcement is the stage architectural guardrails own
Security scanners and architectural guardrails solve different problems
Avoiding category confusion here matters, because a security-modernization program will already be running several of these tools at once.
| Control | Question it answers |
|---|---|
| SAST / SCA / vulnerability scanners | Is this code vulnerable? |
| IAM / security policy | Is this access permitted? |
| Migration tooling | Can we transform the system? |
| Tests | Does the migrated system work? |
| Architectural guardrails | Did the agent build the system we actually approved? |
AI-assisted modernization may require all of these complementary controls. Mneme does not compete with Snyk, Wiz, or Checkmarx — it addresses the one question none of them are built to answer: whether the architectural constraints a team encoded for the migration were actually enforced while agents did the work.
Conclusion
AI may shorten the time required to replace insecure legacy systems, which is exactly what the collective cyber-defense letter is asking for. It also shortens the window in which architectural mistakes can be introduced at scale, which the letter does not address directly.
The next modernization problem isn't making migrations faster. It's making the target architecture enforceable while agents perform them.