The defense factory

PHP. eMudhra. TiDB Cloud. Railway.

Yesterday was a landmark day in the world of security incidents. Security researchers have been warning us that such a day would come soon and most of us are not prepared.

They all demanded different responses, but unfortunately competed for the same people: your best engineers. The engineers who can trace dependencies, understand production and judge whether an urgent change is safe. Every investigation needs them at once. Feature work stops while teams assemble inventories, find owners, prepare fixes and verify what actually reached production.

Today, Axios reported that major U.S. banks were detecting third-party AI agents accessing customer accounts. According to her sources, executives were struggling to distinguish human activity from agent activity and establish whether customers had authorized the agents’ actions.

These reports describe different problems. Together, they make a strong case for changing how enterprises organize defense.

𝗘𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝘀 𝘀𝗵𝗼𝘂𝗹𝗱 𝗯𝗲 𝗮𝗯𝗹𝗲 𝘁𝗼 𝗴𝘂𝗶𝗱𝗲 𝗮𝗴𝗲𝗻𝘁𝘀 𝗶𝗻 𝗽𝗮𝗿𝗮𝗹𝗹𝗲𝗹

OpenAI’s Defense Factory describes a continuous operation connecting asset inventory, vulnerability investigation, validation, ownership and verified remediation.

Here is how I would apply software factory worker agents to the above incidents.

• 𝗣𝗛𝗣: Inventory affected runtimes across services and container images. Prepare upgrades, rebuild images and run application tests. Verify that production workers actually run the fixed version. A merged PR is not enough to prove that we are in the clear.

• 𝗲𝗠𝘂𝗱𝗵𝗿𝗮: Trace certificate trust across operating systems, libraries and binaries. Identify clients still trusting the compromised intermediates, prepare updates and test both rejection of compromised chains and continued operation of legitimate connections. A protected browser does not mean a backend service’s trust store is also protected.

• 𝗧𝗶𝗗𝗕 𝗖𝗹𝗼𝘂𝗱: Map the vendor’s confirmed exposure categories to the enterprise’s own usage. Identify potentially affected accounts and integrations, investigate credential exposure and prepare rotation plans.

• 𝗥𝗮𝗶𝗹𝘄𝗮𝘆: Inventory stored secrets and trace the services they unlock. Coordinate replacement credentials, revocation and checks for unusual activity. Account for the deployment pause when planning how applications receive their new credentials.

Different agents could investigate these workstreams concurrently. Engineers would set priorities, resolve ambiguity and approve consequential actions, with evidence already assembled for review.

𝗧𝗵𝗲 𝗱𝗲𝗳𝗲𝗻𝗱𝗶𝗻𝗴 𝗮𝗴𝗲𝗻𝘁𝘀 𝗻𝗲𝗲𝗱 𝗴𝗼𝘃𝗲𝗿𝗻𝗮𝗻𝗰𝗲 𝘁𝗼𝗼

The banking report adds a requirement that faster patching alone cannot address: understanding who authorized an agent and what that authorization permits.

For the agents an enterprise operates, that means identifiable owners, scoped credentials, explicit action boundaries and audit records. Investigating a suspicious session should require less authority than revoking access or changing production.

Customer-facing systems also need ways to establish delegated authority and recover when it is abused. A defense factory could help investigate and coordinate that response, but the underlying identity and authorization controls still need to exist.

OpenAI makes a useful distinction here: expanding the work agents can investigate is separate from expanding what they may change. Greater autonomy should follow demonstrated reliability.

𝗦𝗲𝗹𝗳-𝗶𝗺𝗽𝗿𝗼𝘃𝗲𝗺𝗲𝗻𝘁 𝗯𝗲𝗹𝗼𝗻𝗴𝘀 𝗮𝘁 𝘁𝗵𝗲 𝗰𝗼𝗿𝗲

Every response exposes weaknesses in the response system itself.

An agent misses a bundled trust store. A rotation breaks a dependent service. An investigation treats missing logs as evidence that nothing happened. A patch passes CI while an old worker stays live.

Those failures should become private evals.

Self-improvement agents can reconstruct where the response failed, propose changes to skills, tests and runbooks, and replay historical cases to check whether the changes improve results without introducing regressions. Engineers review the evidence and approve the exact changes that go live.

OpenAI describes versioned triage instructions, repeatable evaluations and lessons captured in shared context and reusable skills. Enterprises can build on that discipline.

The goal is a defense operation that rapidly responds to several emergencies at once and becomes more dependable after each one. Your best engineers should spend progressively less time repeating investigations and more time deciding how to protect the business.

Sources and further reading:

OpenAI’s Defense Factory: https://openai.com/the-defense-factory/

PHP security advisory: https://www.php.net/

Mozilla on eMudhra: https://blog.mozilla.org/security/2026/10/20/protecting-firefox-users-following-the-compromise-of-emudhra-intermediate-certificates/

PingCAP incident report: https://www.pingcap.com/trust-hub/security/security-update-october-2026/

Railway security disclosure: https://blog.railway.com/p/security-disclosure-wednesday-october-21st