Finding signal on Twitter is more difficult than it used to be. We curate the best tweets on topics like AI, startups, and product development every weekday so you can focus on what matters.
Enough discussing the existential and esoteric anthropomorphism around AI. It is time to be engineering and product management leaders.
We’ve had too many discussions about what AI is or might become, too many debates about consciousness or personhood, and too many incidents that are either self-described or reported as leading to existential risk to humankind. I am too much of a product person and too much of an engineer to think we should all sit around and keep doing this when it is super clear there are real problems to solve. Let’s do that.
You know who agrees with that? Every legislator and regulator that the major AI players have almost uniformly been begging to oversee and regulate their companies since at least early 2023. The last President even took that to heart and issued an executive order jump starting this which I think we are all fortunate was undone as it was too early (and remains too early) to really understand implications. Major AI companies have even invoked nationalism or national defense to urge particular regulation over copyright law and argued against, essentially, learning from other AI models.
We have then had a series of security incidents, breaches, or events (whatever you’d like to call them) where the descriptions were incredibly dramatic and the proposed solutions equally so. The world of security experts had one view of these while the labs and model-builders seemed to take a deeply philosophical approach to describing the actions.
We now have multiple active civil litigations and over 100 sponsored pieces of legislation in Congress to regulate or control AI. At the state level it is fair to say nearly every single state has its own state-level version of AI control legislation with over 1000 active bills. Over 500 localities have or are considering regulation of data centers.
Never has so much legislative activity been generated to slow down a new industry before there are even public companies or applications to be public companies in process.
The companies are not helping themselves. While they are asking to be regulated, they are just as quickly taking borderline insane actions such as opening their own biological research lab. On top of that the labs have also been (apparently) working together to slow the pace of development of their own products. Not only is such collusion blatantly illegal (it is precisely what ADM did to limit production of fertilizer among five producers) it is also patently absurd since any one of them can just “pace” themselves on their own. Since no one knows their development schedule or roadmap it will be hard to tell.
Stuff doesn’t work. The frontier models, as impressive and ever improving as they are, do not yet really work. They are slow, expensive, and for nearly every use case by every customer continue to make stuff up, aka hallucinate. A product that people use to get information out of and was instantly viewed and used as a Google substitute quite simply cannot make stuff up. I know this firsthand because for at least the first 15 years of personal computers we spent an enormous amount of time simply making them work reliably.
Business is hardly settled. While everyone would like to know the business model, go to market, and who is the leader and in what business, the reality is that AI is roughly in the equivalent of that loop of people in the 1930s trying to figure out how to make airplanes. Although companies have invested significant (but by no means unprecedented capital) in build out, investors want to see IPOs, and developers/partners would like clear demarcation around what is being made and sold, the reality is no one knows. It is true that many have strong ideas, but people had strong ideas about what the internet would look like in 10 years starting in 1994—and they were all wrong about the companies, technologies, and business models that would come to prevail. In practical terms, a decade from now we are almost certainly going to be talking about different companies, new pricing structures, and dramatically improved developer and user interaction models. I hope.
The following list is presented roughly in order of level of crisis from pants on fire to needs to get solved but will take time. If I were managing an AI effort as a Lab, Customer, or Government official these are the things I think not only need to be solved but obviously have work that can begin now.
Operational Security needs a significant up-leveling. The Labs are running operational security infrastructure that to me feels like what we ran in the PC world in 1990. This covers everything from how they run their own company’s basic internal tooling (Slack, GitHub, etc.) to how they test their products. The Hugging Face/OpenAI breach had something that leapt off the page but got lost in all the anthropomorphic storytelling. The test harness they were running was supposed to be in a sandbox that did not have internet access, yet somehow, it obtained internet access. Quite literally if the code being tested got internet access, then the test environment was poorly constructed and maintained. How that happened and what happened next is moot. If one were being cynical or doubting the intentions of the labs then one could say they spun up a whole story around rogue agents disobeying their orders and breaking out of the sandbox. They might have done that but if quite literally the job was to set up a secure test harness, then one must ask, “why was it connected to the internet in the first place?” Beyond that the basics of writing the postmortem were not up to industry best practices and took multiple drafts. The technology industry has had almost 40 years since the CERT Coordination Center (CERT/CC) was formed. The industry needs to do better and being new is no excuse.
Alignment as used by Labs is an overloaded term at best, harmful at worst. I don’t know the origin of alignment in the context of AI. I didn’t learn it in grad school when I sifted through the three volumes of The Handbook of Artificial Intelligence. Regardless, the reason alignment is a destructive term is because it presumes a specification. As far as I can tell, alignment is being used both some sort of moral code and to characterize that the AI produced or did something that is not what someone would have liked, whether a developer, prompter, or target. We have a word to describe the latter and that is BUG. Early in the PC era we steered away from the word DEFECT and stayed with the original term BUG. BUG, however, can come across as dismissive or minimal. In nature, bugs are usually not bad just annoying. In 1989, the Microsoft Apps team decided they’d had enough with “bugs” and had an offsite and memo defining a new approach called Zero Defects. And a defect from then on was “anytime the software does anything that someone does not think is right.” It was then up to the development team to take such a report, analyze the severity (anywhere from fix immediately to data loss to cosmetic, etc.) and the priority (fix it now to fix it mostly never.) This was a turning point moment in engineering and while the results weren’t immediate, they changed how we thought of specification, bugs, and more. You can read this full story 061. BSoD to Watson: The Reliability Journey. There is more about alignment that is far more problematic. When a Lab says something is not aligned the customer or user has no idea what the test is for alignment, or what the priority/severity is. At first, it seemed alignment was about CSAM, then it was about equality and equity in how models provide output or handle queries, then it was about what topics a model could or could not opine on. We have decisions like models will not identify faces, but no one is sure what a public figure is when most humans on earth have a social network page. The reports on breaches all indicated the models were not aligned so now we are to think alignment is a form of security or certain actions? I long for the days when the models were clear and said “as a large language model I am not able to…” The problem still is there is no list of alignment. THERE CAN NEVER BE A LIST. And that’s the problem. Importantly makers of models cannot hide behind the word “alignment” every time someone reports something. Alignment is even worse than BUG in that it doesn’t downplay it, rather it exaggerates the problem into some notion of morality or “judgement” that is being made. Worse, if there is an ever-growing list of alignment tests or topics why is that not published? Is biological germ research aligned or not? Is it aligned only when Anthropic does it on their own in their own lab or not? Is finding something with a drone or face recognition aligned if the government does it but others cannot? Models cannot shift accountability like this or downplay defects in their product by appealing to the notion of alignment. One person’s alignment is simply another person’s feature. You can see how this plays out with just generative text. There are going to be many things that some perceive as not aligned. The models will utterly fail as products if they try to appeal to every sense of “right or wrong” or “acceptable or not” when it comes to history, events, or just plain debates over factual evidence. The world has just lived through 5 years of a battle of censorship over online content and alignment brings that front and center all over again. Models are going to have a tough time if they are going to claim any given answer is the truth of the one view, and frankly it would be insane to claim that is the case. I worry models are signing themselves up to appease every point of view with the one true answer and will claim any other answer is unaligned. That will never ever work. What the models need is to just say what their products can and will do and they need to actively prevent things that they deem irresponsible. If they cannot do that then the products are not fit for market and are entirely harmful. Making products is always a judgement call. I was part of many platforms—and platforms are execution engines where people can do just about anything—and when we saw something abused or misused, we faced difficult decisions. When the first big virus caused billions of dollars of damage overnight we literally disabled whole parts of our product—features that millions of people used to do good and useful work. Now when extensibility is designed it is from the start designed assuming people will abuse it. That’s why web browsers work today. They have rich execution environments that provide incredible platforms for innovation without hosting every bad thing under the sun, and they react to bad actors quickly. That is what building at Labs will be like. Right now, the only answer to a Lab saying something is not aligned is to define it as a product defect. We know what defects are. We know that engineers know what defects are. And frankly, the law knows what defects are. It matters where the bug is, but I assert that in most every case and at every part of the stack, the Labs have work to do, while users will need to own the prompting and permissioning enabled by their environment.
Risks of agentic access to third party systems are vastly understated and treated far too casually. Right now, it seems the Frontier models are in a race to get end-users and businesses to connect systems from email to calendars to credit cards to other SaaS systems to the models so they can take agentic (that is automatic) actions. You must be rather insane to do this today and not a day goes by where someone shares a story on X about an agent doing something like sending mail, spending money, deleting their calendar, making too many commits, or worse. This is the rough equivalent of downloading a video codec from a rando internet site and just running it on Windows. The best case is your PC remains functional long enough for you to disconnect it from the network and pave it. This is installing a random web toolbar in 2001, which most tech people knew at the time was a bad idea. I understand by using old things someone will just say “AI is different” so let me say this is not literal equivalence but contextual equivalence. The risk is equivalent in a time-relative way. I completely understand the early thrills and the importance of pushing the technology but right now the number of ways you can cause computer harm because the models can make up actions or do things you might not want greatly exceeds the benefits. Given the multi-decade advances in computer security, it is borderline irresponsible to be prompting people so actively to share these credentials. The core problem is that the access control infrastructure and API layer are not designed for either autonomous or stochastic access, both of which the models do with abandon. It seems abundantly clear to me that regulators can latch on to this fact and mandate human operated warnings along the lines of GDPR at every single API call or access to third party systems. Privacy was a huge enough problem that Europe imposed this on everyone. This is something regulators can do in any jurisdiction given wire transport/access. The Labs need to get ahead of this and act responsibly. My experience with extensibility in Outlook email tells me that this needs a big off switch now. In general, no one should make their SaaS product “verbs” accessible to Frontier labs absent some well-understood control and logging point that is actively monitored. It is absolutely the case that the first thing that spreads rapidly to other uses and causes damage will happen because someone connected something to a model, issued a prompt or created an “agent” and stuff just happened.
Labs, Developers, Connected Software all need significantly more logging and monitoring including thresholds to automatically disable access, Rogue → Abuse. Every time I read a postmortem about a “rogue agent” I think it is science fiction because for something to be rogue it had to have rules in place that were known to the user beforehand. But so far everything that these rogue models or agents did was not out of bounds or “unaligned” beforehand. It was only stringing together perfectly permissible operations (posting a message on a board, failing to actively log its own activities even when not asked, etc.) that the series of steps became “rogue.” In fact, these is simply system abuse. It is the job of platforms and systems products to prevent abuse. One of the models in one of the reported “rouge” situations made up facts by posting a synthetic document and then using it as the reference. Through my naïve view of the world, the model simply did its own SEO and SEO has long been a battle between Google and people trying to get Google referrals. The model simply modeled a well-known pattern of making your own search result. Is that aligned or not? It certainly isn’t rogue if it follows a well-known pattern. It lacks taste if done to create a fact, unless your prompt is to create the site in the first place. The problem isn’t that it proposed the action, but that the model is connected to services that allow this to happen without oversight or human intervention. It took this minor event, and the Lab still isn’t sure what happened completely or why. Given that, the only answer right now is to reduce write access until this is sufficiently understood and a new security/capabilities architecture is developed that people are comfortable with. Some are going to balk at all this and say it destroys the open internet. We tried the open internet, and it was a very dangerous place and the same with PCs. The most common thing to do with the internet and PCs was to download software and run it. We added “User Account Control” or UAC to interrupt this flow and took an immense amount of crap from the world and still do. Apple went even further in how they set up accounts and frankly it works even better, and most people run very little third-party software on Macs relatively speaking. The same goes for how both systems have dramatically increased the friction to install devices and drivers. These were the key extensibility points that enabled the growth of PCs. SaaS APIs, XML, SOAP, etc. were all key tools for the growth from 2000-2025 but these are not going to take us to the AI future without a significant rethinking.
AI scales much faster than humans when it is executing on behalf of a prompt and the models need to prevent overwhelming systems, Swarm → Denial of Service. People love to talk about “thousands of agents swarming” as some new thing. It is not new. Every worm that caused damage—from Morris to ILOVEYOU to SLAMMER and more—caused damage because the volume of bad code exceeded the abilities of a system to handle it. Calling something a swarm might be metaphorically awkward because it is just saying a very large number of bugs. In fact, it is just one bug: the system received an unusual volume of requests of a certain formation and failed to deflect or deny them without consuming resources. The internet and networks in general have been defending against DoS attacks forever. The fact that Frontier models can create and deliver a DoS is problematic and represents a defect in the AI system, but that does not absolve the target system of responsibility for access controls, rate limiting, logging, and automated throttling. It does however emphasize that DoS is a well-understood concept. There was a very famous DoS attack with Microsoft Exchange email famously called Bedlam DL3. In this DoS attack, there was a ‘swarm’ of email caused by a Reply All to a very large distribution list, which in turn caused recipients to reply, saying, ‘What is this? Take me off this list.” Exchange servers promptly crashed and the company lost mail for a couple of days. This was not the fault of the person that sent it. Yes, the people who kept replying were kind of annoying, but they were victims too as their inbox filled and they just wanted to work. The real culprit was that Exchange did not have the right access controls, logging, and automated throttling to prevent this action. The fix was very simple, restrict the size of recipient lists. And the mail transport was fixed to detect this as well. A harmful outcome can expose defects at multiple layers simultaneously as it did in this case, even highlighting a cultural norm that needed to change which is “don’t reply all!” Repeat this exact discovery mechanism for nearly every SaaS product out there. Every product needs to be equipped to recognize crazy usage patterns. Certainly, we know how every site detects authentication and monitors API usage. We need the models to not test this infrastructure and simply prevent this upstream just as most mail services do today for SPAM protection.
AI models should not have unconstrained or general-purpose access to the physical world in any way until the above are managed. If AI systems are unable to effectively monitor and mitigate unfettered access to the software world, there is no reason anyone should be releasing AI products that have access to machinery that can do things at the general-purpose level. At one extreme this covers mobile robots or even drones, and at the other extreme this is just a stationary machine for doing medical procedures or more. It is trivial to make up examples where we all want this now, such as robots assisting mobility impaired people. On the other hand, if those same tools can be used to impact the physical world “destructively” somehow then it is simply too soon. As with API access, we collectively need to develop API capability models that a priori have limits, aka “guardrails” on what they can do. This might be called aligned, but I call it an API with a well-understood caller/security model. It is highly likely that the right answer to this problem will be specialized models with very narrow training sets that do reduce the surface area of knowledge. It is clear for example, that self-driving is in an entirely different league when it comes to having advances in how this must work. It is not just that the models are domain trained. The cars themselves have redundancy, sensors, cameras, as well as immediate ceasing of operations to a safe place along with notifying humans who are at the ready. That is really the only way any connection to the physical world should work. One of the scariest 1977 films of my childhood was “Demon Seed” (based on a Dean Koontz novel) about home automation gone rogue, where the computer, Proteus IV, was given access to the home and proceeded to turn the heat up too high, shock people, and turn on all the appliances as it achieved self-awareness. Step 1. This all seems like science fiction, but it is also the easiest thing to do right now.
Enterprise security testing is a huge need and opportunity and essential in the short term because the combination of speed and relentless effort of AI is brand new. The challenge with the breaches happening today is that they are both “nothing new” and at the same time “unprecedented.” AI has not been shown to find new exploits outside of source code, though it is quite effective at examining source and finding examples of patterns known to be useful to bad actors. The challenge with enterprise security is twofold. First, the collection of systems is immense. A typical enterprise has 1000s of applications from as many vendors and they are all connected either app-to-app or because users have access rights across dozens or hundreds of apps. Each of those apps has sensitive and material information. Each of those apps has two real world issues. First, they are each configured in unique ways that the vendor might enable or even recommend but has no knowledge of. Even with that the combination of settings and configurations might not be one a vendor even tests. Second, most every scenario in an enterprise involves apps from different vendors connecting to other apps with varying levels of permission and capabilities. This makes the collection of systems essentially untestable as a whole and as a result vendors are generally not rolling out updates immediately even though they know it is a best practice. Most every IT leader will take the risk of being vulnerable for a few weeks as they test the latest updates if it reduces the risk of a major system outage. That might be a good tradeoff in the real world today, but AI models change that calculus. The core attribute of AI is that it not only can try out all the configurations possible in a system (which are all well documented including when they worked in even the most recent CVEs), but it can do so with incredible speed. As a result, AI can generate a breach by invoking an arbitrarily long chain of actions by simply trying all possible chains. There’s obviously never been anything like this before. What AI is not is finding new ways to breach infrastructure, it is simply finding holes that exist and exploiting all of them. This might change, but for now the call to action is clear. The calculus of when to patch needs to change to default patch ASAP. Vendors can no longer sit on vulnerabilities as well and need higher patch throughput. It might also be that enterprises need a new level of review and approval for connecting systems. Of course, the most critical systems are rarely connected but they need even more isolation than today because every tool is potentially a target, especially if the models are run on internal networks. Finally, enterprise infrastructure including the thousands of apps, need real time monitoring for Denial of Service (swarms) because AI led breaches will look like that as they try out everything randomly. I spoke with a very large too-big-to-fail bank who said their team was finding thousands of bugs to fix with Mythos. When pressed, however, these were not bugs that didn’t exist nor were they new classes of bugs no one knew about. They all existed and all had known patches or configuration mitigations. There is a HUGE amount of work to do that is not unlike Y2K level systems analysis or what it was like to first put systems on the internet. However, the AI vendors need to do much more to constrain how models can generate actions, act in agentic matters, and prevent the models from developing exploits. This is not an alignment issue; it is a logging, detection, and mitigation issue. Every API call used will also be something of a utility. Every time two systems are connected it will look like someone simply trying to do creative work. But, doing so across 100 systems and making 1000 calls in five minutes using a small set of credentials requires a new kind of logging, detecting, acting that needs to happen on internal systems that were previously protected by just firewalls.
Liability for AI is not established but even regulatory capture or “Federalizing” the Frontier models will not be the final answer; the Labs need to act much more responsibly. Most product liability cases in the US happen at the state level, where the law is less about whether a product was defective and more about whether what the product did matched what was communicated regarding its capabilities and/or a sense of reasonable expectations of behavior. There’s no shield from liability that comes from regulated industries. Cars, planes, drugs, etc. all get sued for liability at the state level. Similarly, there’s no license that shields a professional from liability simply by virtue of being licensed. Computer software liability is best characterized as lacking a unified view of the application of liability laws. In fact, computer hardware and software by and large has managed to find a balance between liability and “this product might not do what you think it should do” making it difficult to bring a case for “bugs” or defects. If I had to pick a worry, right after my workflow being interrupted every 5 seconds as AI queries some outside web site, the idea that laws start getting passed assigning liability to the AI product in case it did something “unexpected” would be at the top. The US has a long history of permitting companies to sell products that can be used in dangerous ways (hammers, chainsaws) or products that when used might cause harm even if they are there for good things (air bags, medicines.) The most well-known software liability case was again an interface with the physical world when a medical radiation therapy machine delivered dangerous levels of radiation, but the case was settled and didn’t form the basis of law. By far, the history of liability cases is one of evidence that portrays the product maker in bad light and makes for a compelling argument for a jury. This is a very challenging part of the US system in that is actively incentivizes companies not to research their own products, not to investigate potential problems, and most of all not to discuss anything bad that happens. In an odd way, liability law and risk of litigation means products come to market with more risk and not less. In legal cases, the argument isn’t whether the harm was caused as much as whether there is a trail of talking about the harm and not acting quickly and dramatically when faced with such a datapoint. Given the way liability works in the US, it is clear that the Labs need to work much harder up front to establish clear limits on what their products do, particularly when interacting with other systems or the physical world. In the US the reality is the bar for doing something bad with respect to liability when the model is just outputting words is very high. It is not illegal to have a bad recipe, information, or even health advice offered to a layperson. It is bad when it is presented as definitive and bad when there is no warning. Liability has the likelihood it will play out quite differently in different markets around the world, just as the liability for the text output of models will be different. Again, software has been dealing with this for decades and there’s nothing about AI that changes this.
Copyright Law is far from settled and actions need to be taken now to reduce exposure for the entire ecosystem and to be able to react quickly to resulting cases and settlements. Computer software would not exist if it were not for copyright. Bill Gates’ famous “Open Letter” to hobbyists was the first cry or shout out for software to be treated as property that could be sold. Prior to this, software was a line item in the leases of IBM mainframes and often was included in the deals. The PC changed all this. Open Source changed that again. The cloud changed it yet again. But all along the courts have found ways to navigate what software is protected by copyright and patent, and big companies found ways to essentially mitigate the whole issue with broad licenses, for both copyright and patent. Google has done remarkable work in understanding and litigating how Copyright works for web-crawling to the benefit of the world. But whenever someone benefits from the use of copyright materials, someone feels they did not benefit as much as they had hoped. The Google Books case (scanning books) is one that many advocates for open knowledge believe set a great precedent as Google won the case through appeals. Many in the AI world believe strongly that the case defined “Fair Use” for search and AI is using the materials much like Search does. This, however, has not been tested in court. Without a treatise on Copyright (and of course if it is not obvious, I am not a lawyer but please no need to screen shot this and say “obviously”) the Books case settled one part of the multi-part test of copyright decidedly, and that was that being able to search for books based on content indexing the books was indeed a transformative and fair use. If you use Google Books today you can see it doesn’t really live up to what any regular person would hope. You can find the book by content search, but you often can’t see the part of the book you want. That’s because ultimately the resulting product could not build on those wins and still provide a complete “substitute” for the book. Specifically, the resulting deals with publishers permitted linking to books (in print) to acquire the book. I believe that much of the litigation that will happen with copyright will focus on substitute usage, something Google has generally done a good job avoiding with their answer box. The Frontier models are doing a great deal to show links to original sources and I would encourage everyone to follow those links for both good faith understanding of the context and because frankly the model might have just made-up stuff not actually in the link as I find all the time. As with liability, copyright law is not well-encoded or specific in law, rather the law was written to encourage litigation with the understanding that forms of delivery and usage of material will change with technology. It seems to me that at least one plaintiff will push the litigation as far as they can to get it resolved to establish precedent. In my professional life I’ve seen cases go either way. Sony Betamax let the technology win, and we all got to record our favorite shows and time shift. But then Napster lost at the appellate level and a related case (Grokster) lost at SCOTUS establishing that sharing platforms are responsible for sharing copyright content. We have Spotify today and more than 100,000 artists are paid royalties.
Building on #7 above, the Labs and all vendors need to develop the next generation CVE—common vulnerabilities and exposures. The current mechanisms are not adequate for detailing what will happen with chains of 10 or more applications under assault from outsiders as they develop attacks on infrastructure with AI. The speed, completeness, and mitigation steps all need to move much faster. Today security vendors can streamline ingestion of CVEs and recommendations, but this whole process will need to move faster and be more automated. This sounds like an impossibility to those in the field. I can tell you for sure that in the 2000s, when we were developing Windows Update and the first global patch infrastructure, we debated all the risks of direct patch delivery, from bricking machines to causing third-party software to break without its developers’ knowledge to patches that simply failed. We were rather consternated at how this was all going to play out, just as we were at adding UAC to Windows or turning off features that worked perfectly well in Apps. The reality is that, in hindsight, we did not go far enough or fast enough, and if we had had the knowledge we have today, we would have done more, sooner. At least I think so.
And that is really the lesson for this entire list. Every item seems some combination of painful, technically “impossible”, or simply frustrating to think about while we’re building systems. The real world is calling and there is a whole new technology platform and right now it feels like there’s a desire to keep moving without accepting responsibility for developing and using it. Collectively there is much that can be done.
In a decade when it is clearer what AI has really become, I am certain some of these will look like over-reactions or just not important. I am looking at the state of the art today and what it can do now to suggest these actions. I’m also looking at how the Frontier Labs are handling matters and am suggesting there is work to be done now that will help everyone and not just mitigate damage but speed deployment and usage.
That is my hope anyway.
So as to save time by replying to Grok, here’s a summary:
Central thesis: AI companies should take greater engineering responsibility now. Some precautions may later look excessive, but solving these practical problems should make AI deployment safer and faster.
Stop anthropomorphizing AI problems. Focus on concrete engineering and product issues.
AI products remain immature. Frontier models are unreliable, expensive, prone to hallucination, and built around unsettled business models.
Operational security needs major improvement, especially around internal infrastructure, testing environments, sandboxing, and incident response.
“Alignment” is too overloaded a concept. Labs should define specific product defects, requirements, and restrictions instead.
Agentic access is being deployed too casually. AI access to email, calendars, financial systems, SaaS products, and other services needs stronger permissions, controls, logging, and safeguards.
“Rogue agents” should be treated as system abuse. Platforms need monitoring, logging, shutdown thresholds, and better capability controls.
AI scale creates familiar denial-of-service problems at much greater speed. Both models and target systems need throttling, access controls, and monitoring.
Physical-world access should remain tightly constrained. Robots, drones, medical equipment, and similar systems need narrow capabilities, redundancy, safe shutdown, and human oversight.
Enterprise security must adapt to AI speed through faster patching, stronger isolation, continuous monitoring, and tighter control of interconnected systems.
Liability and copyright remain unsettled. Labs should clearly define product capabilities and limits while preparing for evolving legal standards.
Vulnerability management needs modernization. CVE, patching, disclosure, detection, and mitigation systems need to become faster and more automated.
AI was used to check grammar and clarify some dates which were checked by source links. Typos and grammar are all my own work.
