{TRAPDOOR SECURITY} - product design

Authenticating Authorized Artificial Agents

2026-03-07T00:00:00+00:00

A New Agent to Agent Communication ‘Protocol’ Enters The Ring

For a while now we’ve had Model Context Protocol and there’s been a lot of valid criticism laid at is feet. The running joke appears to be ‘should it just die’? Well what if it did? What other standards exist that would allow for complex agent integrations to exist?

Have you ever used multiple agents in tandem over the internet and thought “wow, this is probably really insecure but Imma do it anyway”?

Now imagine you had absolutely no control over the ‘other agent’, but in order to Get Stuff Done, that’s what you had to do. This is the world in which we are ushering by encouraging the latest fad of Agentic Agents doing Agently things.

This is the lens that I would like to explore these standards through… what happens when we implement them badly? Because we will.

How was the internet built anyway, Unc?

The world of the internet has for the longest time been defined in humble text files. Everything from TCP/IP to DNS and even protocols for brewing coffee remotely exist in these text files. They start out as theoretical pieces, that slowly crystallize over time into real software that you and I use today. I personally find them fascinating to study, both new and old.

The Internet Engineering Task Force (IETF) has been the custodian over these definitions since well before the World Wide Web was even but a twinkle in Tim Berners-Lee’s eye. The Request For Comments or RFC document is the delivery mechanism for much of the fundamental engineering that makes up the internet as we know it.

On March 2, 2026, a new draft RFC landed: “AI Agent Authentication and Authorization”

Arguably, it is one of the more important attempts at defining how the constellation of authn/authz ideas should and might coalesce in the future. While it isn’t pitched as a standard (yet), it is being floated to consolidate the ecosystem and elicit discovery of any gaps.

It is written by people from AWS, Zscaler, Defakto Security and Ping Identity, so one could presume it comes with some experience behind it.

Although, we should never underestimate the ability of nerds to get over-excited about specifications. I have lived the SOAP life and am old enough to remember the WS-* years. XSLT anyone? That felt like a proper fever dream. I don’t want that again. Is this going to be the same?

TL;DR

Thankfully what is going on bears no relation to WS-* as best I can tell. I put ‘protocol’ in inverted commas in the title above, because this paper basically argues that we have all the pieces of the A2A puzzle already, and we simply need to start using them. That said, there are a lot of new concepts (to me, at least). I will list them first with sources and then dive into what the acronyms mean.

The foundational pieces proposed are:

WIMSE/SPIFFE identifiers
OAuth 2.0 identity chaining via Transaction Tokens (for delegation)
mTLS with short-lived SVIDs for authentication

Exhausted yet? Me too. But let’s press on, because where there are complex systems, there are opportunities for flaws, bugs and exploits.

A2A: Service Discovery for a Gen Alpha World

Parallel to this draft RFC is a specification called A2A protocol (Agent 2 Agent). This was built by Google in April 2025 and is now living in the Linux Foundation.

A2A doesn’t talk about identity much at all. Every agent publishes an ‘Agent Card’ on .well-known/agent.json listing its skills and other endpoints. It lists any supported authorization flows, and clients optionally may obtain short-lived OAuth/OIDC tokens that are scoped per task.

However, authentication isn’t defined in this standard in strict terms, only allowing for optional mechanisms, leaving authn an open question.

To summarize, A2A is about defining a schema for agent discovery (the agent card) and a task lifecycle protocol but leaves the identity issue alone, which is where the RFC becomes relevant.

Sounds kind of spiffy!

As with all things on the net, we need an address. A “Uniform Resource Identifier” if you will. To this end, two standards have emerged, WIMSE “Workload Identity in Multi-System Environments” and “Secure Production Identity Framework for Everyone” (SPIFFE).

The URI is important as a way for multi-agent systems to distinguish each other, and SPIFFE also takes care of identifying particular workloads, and their execution contexts. This becomes important later.

All we really need to know at this point is that an agent operating in this version of standards hell, must have a WIMSE, and that WIMSE may be a SPIFFE.

Let’s Take a Deep Breath (LTDB) and remind ourselves that Acronyms Suck Sometimes.

So imagine we have a lovely little robo-helper, let’s call him Agent Bob. He publishes his own Agent ID card at his address, and lists ways in which he can help or be helped. All that is left is that elusive piece: how do we know that Agent Bob, or his neighbour-robo-helper, let’s call her Agent Alice, is who they say they are?

Enter Mutually Assured D̶e̶s̶t̶r̶u̶c̶t̶i̶o̶n̶ Transport Layer Security

So according to this draft, it is mTLS to the rescue for determining authenticity. If Agent Bob is to engage Agent Alice’s help, they will need to be introduced in holy matrimony via an x.509 certificate binding ceremony known as mTLS or Mutual Transport Layer Security.

However it’s not as simple as agreeing on an x.509 certificate. Remember I mentioned that SPIFFE identifies workload execution? It does this in order to reduce risks of compromised certificates, by issuing “Short-Lived SPIFFE Verifiable Identity Documents” or SVIDs. These SVIDs need to be validated before any Agentic Action may be, um, actioned upon.

At this point I am throwing a chair at the next person who makes a new acronym.

But wait! There are more acronyms!

The astute reader may note that in order for any of this to work, agents would need real-world credentials as we already know them, to do anything important behind the scenes! And you’d be right, dear astute reader.

How would existing enterprisey systems provision new identities from places like Entra ID or Active Directory? Via SCIM, of course, which will need an extension also defined as an IETF draft to define an ‘Agent’ resource type, and allows us to assign human owner(s) to our robo-clanker-pals.

If this wasn’t whimsical enough…

Further to the question of how humans might bind their identities to those of agents, is the WIMSE Applicability for AI Agents specification. This specification defines requirements around automating credential management and maintaining the principle of least privilege when it comes to access tokens and workflow management.

Where the battleground of ideas truly lies though, is in defining OAuth extensions that would support you as a human to quickly authorize an agent to act on your behalf.

There are multiple competing drafts for these OAuth extensions from China Mobile and Huawei. This makes some sense that mobile phone manufacturers and technology companies in general would love for us to authorize agents in the same way that we authorize Facebook to login to stuff, they can then set about deriving huge economies of scale and do more vertical integration shenanigans, for example.

China Mobile’s solution appears to define three operational modes where agents could:

operate on a human’s behalf
operate on their own behalf
operate on another agent’s behalf

It also covers integration with Model Context Protocol (MCP) servers or other forms of agentic API proxies.

This raises concerns about long chains of delegation that the average human simply has zero visibility over.

Where there is complexity there are bugs to be found

I think the main areas of implementation that will start to appear in 2026+ will be along these lines.

It’s agents all the way down

What happens when Agt. Bob asks Agt. Alice to ask Agt. Cody to ask Agt. Derek to do something on my behalf? Transaction Tokens and identity chaining are proposed as answers to this problem, but there’s little activity on implementing any of this. Implementations will have to sort out this UX problem as much as the technical one. How do we avoid confusing the everyday user? How do we get past consent fatigue issues for example?

Provisioning is only a small slice of the agent lifecycle

Lifecycle governance: the SCIM extensions cover provisioning, but what happens in terms of runtime enforcement beyond that? Conditional access and behavioural anomaly detection for agents is still an open question.

Federated identity

Cross-domain federation via WIMSE/SPIFFE token exchange in theory allows for agents on disparate cloud providers to work together; however, those CSPs have very little incentive to work together. As soon as they do, they might invite a customer churn scenario that I’ll discuss below.

Human out of the Loop scenarios

Despite a lot of legal pull towards ‘Human in the Loop’, the tech companies seem to be converging on ‘Human very much out of the Loop’ type ideas.

(HvmootL? I made that one up… guess I get the chair!)

Doing Agent to Agent trust well, without human bootstrapping, is the ‘how do we do OpenClaw, but secure this time?’ question.

These standards all assume a human always initiates the OAuth dance. We simply can’t have a secure OpenClaw without truly solving this problem. For this to work, agent workload attestations of some kind are needed to replace the human consent steps.

This is scary territory when you think about it for any length of time, the mind boggles what this would even be used for?!

I guess, to help with that thought experiment, here are some ideas to get you started.

Multi-cloud cost arbitrage… but now with automated workload migration: e.g. an agent monitoring AWS cloud expenditure autonomously negotiates with a GCP broker agent to migrate workloads based on real-time pricing. While this sounds great, this is the scenario I alluded to earlier: CSPs probably don’t want to enable this idea at all because it would turn their pricing into a true commodity auction where agents are buyers. This kind of ‘forex for cloud workloads’ seems like an existential threat to them, rather than a feature IMO.
Incident response swarms: a detection agent identifies lateral movement and spins up forensic collection agents across those environments and isolates them within seconds of detection, in preparation for a human team of DFIR specialists to get involved.

Who would actually want any of this?

While the above might sound cool to some, I’m still on the fence if we truly want that. This new draft RFC draft-klrc-aiagent-auth-00 emphasises trust domains and that agents in different trust domains should not automatically trust each other. However the gap is that at some point in this post-agentic world people now want cross-domain trust to occur. How that gets established is an implementation detail, and this is where security vulnerabilities live.

Now consider that the very people consuming this otherwise high quality set of standards could very well vibe-code large portions of their proprietary implementations. The initial quality ramifications may lead to some catastrophic scenarios.

Standards implemented badly are the norm

Consider what happens if this dance is incorrectly implemented: Agent Bob is compromised, it has a valid workload attestation. Via that attestation, it establishes trust with Agents Alice, Cody and Derek across 3 different trust boundaries.

In an enterprise scenario this could result in some bad outcomes, e.g. the microsoft teams <=> salesforce agent trust is abused leading to exfil via a third agent that had teams trust. All horrible stuff. It’s not new, but it could happen a lot faster.

What I suspect is going to happen is a mass influx of agents into everything. I remember when the first internet fridge hit the scene and how absurd that sounded? Smart fridges are a whole product category now.

I don’t necessarily want any of this to happen but two things are true.

The fad of IoT devices is the example we need to recall.
Agent and API integration just became very cheap to achieve.

Cars is probably the worst scenario I can think of. It’s already happening too, car manufacturers are thinking about getting the right hardware into the cars to run AI workloads today

McLaren just announced their intention to sprinkle agentic fairy dust into their ‘entire engineering lifecycle’, so its probably only a matter of time there too.

If tech companies actually usher in an HvmootL Agent-to-Agent reality like this, these problems really do need to be solved.

Let’s take this to an absurd outcome, imagine A2A protocols are in place, and your car still can install apps from an appstore like it has been able to for a while.

You have an agent embedded in the infotainment unit, and one for commanding the body control module too. Now imagine they’re internet enabled and can optionally order you a pizza while you are driving, that agent has access to a payment token. Heck there could even be connectivity direct to the DMV to allow you to pay your vehicle registration and license renewal.

A single dodgy application installation could theoretically leverage that entire chain of trust to lock your doors, steal your identity, and demand you authorize a payment to a ransomware team. It’s a sobering thought.

OK so we’ve seen all these standards that exist independently of MCP, does that now mean that MCP is redundant? Should it just die and let the IETF drafts take over?

Where is MCP in all this?

Not quite, at least, not for this reason. MCP attempts to solve a different layer of the problem, tool integration, not identity.

To their credit the people presiding over the Model Context Protocol haven’t been sleeping on this issue either. MCP’s auth story has gone through several revisions in a short space of time. Understanding why these changes happened is worth a quick detour.

The original MCP auth design had a fundamental architectural problem: MCP servers were expected to act as both the OAuth Authorization Server and the Resource Server.

If you’ve done any OAuth work, you’ll immediately see why this is bad. It’s like asking the bouncer at the club to also be the one printing the fake IDs.

The MCP server was responsible for issuing tokens, managing client registrations, handling token revocation, and validating those same tokens on incoming requests. This makes every MCP server a high-value target and a compliance nightmare. Suddenly what was supposed to be a lightweight wrapper around your API needs a secure database, stateful session management, and a full security audit.

The June 2025 update to MCP addressed this by formally classifying MCP servers as OAuth Resource Servers. So they validate tokens but never issue them. A separate Authorization Server (your existing IdP — Okta, Auth0, Entra ID, whatever you already have) handles the actual token minting.

To make this work, MCP servers now expose Protected Resource Metadata (RFC 9728), which is basically a machine-readable sign on the door that says “if you want a token to talk to me, go talk to that authz server over there.” This solved the discovery problem, and clients no longer had to guess where to authenticate.

This same update also made Resource Indicators (RFC 8707) mandatory for MCP clients. This one is subtle but important because without RIs, a malicious MCP server could potentially trick a client into obtaining a token scoped for a different MCP server and then replay it.

Resource indicators bind the token to its intended audience, so a token minted for mcp.example.com can’t be redeemed at mcp.evil.com. If you’ve ever seen a token confusion or token mis-redemption attack, this is the mitigation.

The November 2025 revision then made PKCE (Proof Key for Code Exchange) mandatory for all clients, no exceptions.

The reasoning here is that MCP clients are often what OAuth calls “public clients” — agents running in containers, serverless functions, CLI tools, browser extensions — environments where you simply cannot securely store a client secret.

PKCE protects the authorization code exchange by requiring the client to prove it was the one that initiated the flow, even if an attacker intercepts the authorization code in transit. This same revision also introduced Client ID Metadata Documents as the preferred client registration method, moving away from Dynamic Client Registration (which had the uncomfortable property of letting any client register itself with zero paper trail).

All of this substantially shores up the authorization side of the equation. But here’s the rub: authorization is downstream of identity!

All of these mechanisms assume that someone has already authenticated. That a human clicked “Authorize” in a browser window somewhere. The harder question of how a non-human client proves it is who it claims to be, when there’s no human in the loop to click that button, remains unanswered by MCP. This is precisely the gap that the IETF draft and the WIMSE/SPIFFE work are trying to fill.

MCP still not great as a forward thinking standard

In my view the reasons for finding a better solution for MCP lie in a few key areas.

The obvious stuff is just how badly designed it is from a prompt security perspective, and its surface area is single-handedly driving the need for agentic/prompt WAF type products to exist. MCP tools simply return unstructured text making malicious MCP servers a wonderfully effective attack vector.

While MCP design goals are pretty small in scope, because the ecosystem tries to treat it like the ‘everything server’, the principle of least privilege takes a punch to the guts. There is no enforceable permission model in MCP, it’s basically all or nothing, with some hinting to ‘inform decisions’.

In theory OAuth scopes could do this but the mapping between MCP tool names and OAuth scopes is at large, that’s up to the developer and consumer to pre-arrange, it’s not a protocol level concern.

This is driving other MCP governance products to attempt to address the issue, all with variable degrees of success.

Perhaps the worst one from an integration perspective is that there is no inherent agreement on versioning or capability negotiation, so the chances that your agents start misbehaving one afternoon because the MCP started acting differently are pretty high.

In Summary

OK if you made it this far you are officially my [hero|heroine] for surviving the Agentic Onslaught of Acronymonious Anachronisms so I shall reward you with a quick recap.

To answer the initial question I don’t think MCP is going anywhere but I do think the rate of change and the (perhaps misguided) quest to yeet humans out of the loop as much as practical could render it obsolete or force it to start defining or embracing existing identity strategies that support a non-human identity layer.

Whether we should nudge these standards to allow more ‘humans out of the loop’ or not is highly debatable. However, the current state of agent identity is best defined as a “bunch of protocol drafts in a trenchcoat” — it does make a refreshingly sane argument that we don’t really need Yet Another Protocol™, just extend some existing ones. OAuth 2, SPIFFE and mTLS would form the cornerstones of Authorization, Identity Management and Authentication respectively. For service discovery, Google has come to the party with the A2A protocol. There’s some peripheral standards tweaking happening to make it easier to distinguish existing OAuth delegations of authority from agent-to-agent, agent-autonomous and human-to-agent, and for provisioning agent identities in the first place.

However none of this is production-ready and is theoretical until people start to implement code. The closest thing I could find to such a thing is Google’s A2A SDKs in a variety of languages, and I might dissect those and their security ramifications in an upcoming blog post, so stay tuned.

The Cost of Complacency: Why 'Secure by Default' Isn't Just Nice to Have.

2024-08-26T00:00:00+00:00

In an era where cyber threats loom larger than ever, being a good global citizen means prioritizing not just functional software but also security by design. Security is an expected function.

Software isn’t difficult, humans are.

You know that overused joke in software circles about there being two hard things? Well, one of those things, ‘naming things’ I feel extends to defining things, because this is where software’s value actually lies: the interpretation and delivery of human requirements, which are notoriously difficult to pinpoint sometimes.

Example time, “Make the car drive autonomously” might look like a requirement to the average person, but in fact it is more of a desirement because it doesn’t adequately express the complexities involved such that two different designs would both meet a standard. Did you mean safely? What does that mean? Should it drive on the left or the right side of the road? Oh, it’s country dependent? How will it know, oh, so it needs GPS. Right. What if that fails? *

So we need to understand, that to a product team, saying ‘secure by default plzkthxbai’ is really just a way of being annoying and 100% non-constructive. They know it’s a good idea, just… how?

Why do we even care about secure by default?

OK so, I’ll admit, if somebody says to me that secure by default is not a priority, I get a bit hot-blooded. It makes me want to lean into the fact that I’m a grumpy old man and tell the war stories again.

Reality is though, people clutch their pearls every time something awful happens, but nothing materially changes the status quo.

The Morris Worm incident

In 1988, an enterprising young student named Robert created what he thought was a harmless experiment, presumably, to measure the size of … um… the Internet. (Morris is reported to have stated that he only did it to see if it could be done.)

However, his program relied on a default password and a buffer overflow vulnerability in the canonical email service of the day: sendmail - a Unix program.

He designed a self replication component to his program, and before he could say ‘off by one error’ he had infected around 10% of the Internets servers at the time (approx 6000 machines), and caused millions of dollars damage in lost productivity.

This moment was pretty significant, in that it hadn’t really happened on this scale before, but it also perfectly demonstrates why having insecure defaults opens us up to one of the nastiest types of malware: the worm - a self replicating program capable of spreading itself without user interactions.

The Code Red Incident

Another example: we used to be OK with Windows Server 2003 leaving port 445 (SMB protocol) open on install. Code Red made especially good use of this fact - some of you will remember - their cyberattack of 2001 which targeted another default configuration in IIS (open port 80). 24 hours, 350000 servers brought to their knees, billions in lost productivity. (Moore, Shannon, Klaffy 2002)

You can see where the product design decisions come from: make the Internet easy to play with! Make networking easy! Minimize the clicks a server admin needs to take in order to ‘get online’! All laudable, money making ideas. Entirely insecure.

Alas, these weren’t entirely addressed until 5 years later, in Windows Server 2008 as Microsoft now had the ‘very insecure’ label that they probably wanted to shake.

Fast forward to 2024: IPv6 has the same problem

It has recently been revealed that IPv6 had a vulnerability, causing concern among IT professionals.

The reason for this is that it also is ‘wormable’. Why is that? How can a bug in an internet protocol do that, when there was no default password?

In this case, the issue is that many devices and indeed operating systems, enable IPv6 by default, even though they don’t strictly need it. Combine that fact with the remote code execution vulnerability in IPv6, and suddenly, we have a worm.

Conclusion: Water is wet and investors don’t care.

All this did not ruin Microsoft, Unix still exists today, SMB is still a protocol that is used. So, none of the impacts where so bad that humanity cancelled them from all relevance. This tale is repeated in the Solarwinds breach and Crowdstrike outages of late. Go have a look at Crowdstrike share price, I dare you.

Now look at Equifax.

It would seem that lost productivity makes for a good (bad?) news story, but as a society, I don’t think we value it as much as journalists would have you believe. Surely, we move to fix things all-proper-like when people die though, right?

Right?

Stuxnet, WannaCry, Ransomware in general, heck arguably, even the old Therac-25 Radiation Therapy Machine of the 1980s were all situations where human lives could have been, if not were, affected because of insecure by design or other design flaws we would consider to be security adjacent.

So no, fact is, when it all comes down to the cold hard math of making said crusts, people (not just ‘big evil companies’ I might add), put their earning potential ahead of all else.

This is extremely short-sighted

At the moment we enjoy relatively cheap technology, maybe a few more ads than I’d like, but for those with enough means to purchase a device, much of the software you need to make your life easier is near enough to free.

The thing that does change though, is the rate at which we embed technology into the critical parts of our lives. This is a given.

In order to protect lives, we are now looking at the alternative solution to businesses regulating themselves. Of course, I mean governments doing the regulation bit. And this will make everything more expensive.

Where businesses fail to act, governments step in

Remember when cars didn’t have seat belts? OK, so I don’t either, but that was a big issue in the 60s, people were dying enough that Ralph Nader wrote a book about it.

That led to loads of litigation and then government regulation, and finally, a massive increase in safety.

It also added well over 10% to the price of a car, depending on what sources you refer to. Could businesses have avoided this? Could cars have been cheaper and safer?

So given the above, in my opinion, tech companies will have their ‘Ralph Nader’ moment in the future, and until then, things aren’t likely to change.

The US Government is actually doing something meaningful to prevent the repeat of history

Enter the CISA recommendations of 2023, which is the first attempt at a government (that I’m aware of, at least), that tries to properly define ‘secure by design’.

The subtext is often missed though. CISA is trying to give us all a massive hint: “start doing these things before we force you to do them.” They know that the lawsuits are coming, governments are even enabling them, as one of the biggest customers of technology, this makes perfect sense.

What if we adopted the CISA recommendations then…

Alright, so you want to be a good global citizen and make software that is secure by design? First up. Thank you, for trying to play the long game, and make software cheaper for everyone by raising the bar and customers expectations!

There is no single solution to end the persistent threat of malicious cyber actors exploiting technology vulnerabilities, and products that are “secure by design” will continue to suffer vulnerabilities; however, a large set of vulnerabilities are due to a relatively small subset of root causes

-Secure by Design: Principles and Approaches to Secure By Design Software, CISA, 2023

In this document two definitions now exist that you can hang your hat on as a product designer, or software engineer.

Secure by design

“Secure by design” means that technology products are built in a way that reasonably protects against malicious cyber actors successfully gaining access to devices, data, and connected infrastructure Software manufacturers should perform a risk assessment to identify and enumerate prevalent cyber threats to critical systems, and then include protections in product blueprints that account for the evolving cyber threat landscape.

Secure by default

“Secure by default” means products are resilient against prevalent exploitation techniques out of the box without added charge These products protect against the most prevalent threats and vulnerabilities without end-users having to take additional steps to secure them Secure by default products are designed to make customers acutely aware that when they deviate from safe defaults, they are increasing the likelihood of compromise unless they implement additional compensatory controls Secure by default is a form of secure by design

Security should not be a luxury option, but should be considered a right [that] customers receive without negotiating or paying more.

Honestly, there are so many good reasons to read this paper, just do it.

Summarizing for you though, they do a great job of boiling this down to three core principles that any business owner can apply to their company.

Take ownership of customer security outcomes
Embrace radical transparency and accountability
Build organizational structure and leadership to achieve these goals

For product designers and engineers we go deeper:

Memory safe language use
Lean on hardware that can use fine-grained memory protection
Acquire and maintain secure software components (yes, this means libraries and middleware)
Lean on web frameworks that properly escape inputs
Use parameterized database queries to avoid injection flaws
Use static and dynamic application security testing tools to assist in error detection
Code review should be a thing you do (i.e. QA)
Provide an SBoM
Establish Vulnerability Disclosure programs
Include root cause or CWE references in CVE reports
Design infrastructure such that the compromise of a single security control does not result in total system compromise.
Meet a baseline of Cybersecurity Performance Goals, which are too numerous to mention in this article, use this link as reference instead.

At what cost?

Every time we have a ‘black swan’ event your customers governments are more likely to react with legislation. If you simply build like this today, you amortize that cost over the course of years, not months. A recent estimate puts this cost in the US at “$300 billion annually, only $53 billion less than firms spend on corporate income taxes.” (T)

Your customers and investors probably won’t notice immediately, but when your competitors jack their prices up, you’ll be smugly pointing to all the good work you did over the past few years and reaping the churn.

History shows us that without proactive measures from within, industries often face stringent external regulations. By adopting CISA’s 2023 recommendations now, technology companies can not only avert crises but also pave the way for a safer digital future. It’s not just about avoiding penalties—it’s about leading the charge towards a more secure world. What steps will you take to ensure your products are secure by design?

Final thought, consider how much government regulation costs other industries and start factoring it into your strategic thinking, today. Because the warning shots have been fired.

*- Complete aside: In the author’s opinion, this is why, time and time again, ‘no code’ solutions fail to live up to expectations (because they produce an unmaintainable mess that defies to be safely modified) and, why the armies of new wave AI-only ‘programmers’ aren’t taking all the jobs in IT (because programming isn’t the only skill we’re hiring for here).

References

https://www.abc.net.au/news/2017-05-14/ransomware-cyberattack-threat-lingers-as-people-return-to-work/8525554
https://www.wired.com/2002/01/find-the-cost-of-virus-freedom/
Code-red: case study on the spread and victims of an internet worm, D. Moore, C. Shannon, K. Claffy, https://dl.acm.org/doi/10.1145/637201.637244
The Internet Worm Program: An Analysis, Eugene H. Spafford, 1988 https://spaf.cerias.purdue.edu/tech-reps/823.pdf
https://x.com/paulg/status/1323246618326507524
https://www.theregister.com/2024/08/14/august_patch_tuesday_ipv6/
https://www.cisa.gov/resources-tools/resources/secure-by-design
https://www.sec.gov/newsroom/press-releases/2023-139
https://www.theregreview.org/2024/02/28/hoguet-estimating-the-impact-of-regulation-on-business/
https://obamawhitehouse.archives.gov/omb/inforeg_intro