Key Takeaways:<\/p>\n
AI has pushed security to the forefront, helping attackers find vulnerabilities in chips and the chip industry to defend against them.
\nSecurity needs to extend throughout a chip\u2019s lifetime, but it\u2019s not clear how AI will age with a chip.
\nAI pushes visibility outside a chip, which changes the dynamics for how to secure it.<\/p>\n
AI is making it both easier and more difficult to secure electronic devices, amassing an enormous list of known and potential system vulnerabilities that can help prevent cyberattacks, while making it more difficult to secure both hardware and software.<\/p>\n
On the plus side, AI can scrape the Internet for all available research and reports, involving every known component and architecture, and guide engineering teams on the best way to assemble them. It can flag compromised protocols and IP, find hidden keys and side-channel weaknesses that might be overlooked using traditional tools, and adjust for LLM drift and AI agent aging through continuous monitoring.<\/p>\n
The downside is that nearly all data is fair game for AI. A fundamental benefit of AI is its greatest liability, enabling it to access data anywhere within a system, or between systems. But it\u2019s not always clear where or when AI obtains its data, or how that data can be combined with other data. AI is a black box that must be observed from outside a chip or system, rather than using traditional approaches such as monitoring traffic, scanning for viruses and Trojans, and ensuring that passwords and keys are updated regularly.<\/p>\n
As a result, it\u2019s difficult to prevent problems or control AI\u2019s behavior, no matter how AI-savvy the engineering team. In July, OpenAI models escaped from a sandbox<\/a> using a zero-day vulnerability and exposed data from Hugging Face, which is basically the equivalent of GitHub for AI\/ML. Days later, Anthropic revealed<\/a> that its Claude AI assistant was able to access the Internet \u201cfrom within testing environments that should have been sealed off.\u201d<\/p>\n On top of that, Anthropic\u2019s Mythos frontier model can be used to quickly find hardware vulnerabilities that would take the best security experts years to identify, if ever. \u201cThis is technology that is very difficult to put back in the box,\u201d observed Marc Witteman, senior director at Keysight Technologies<\/a>. \u201cAnd there are many organizations working on this, so even if Anthropic is stopped, others will continue.\u201d<\/p>\n What\u2019s particularly dangerous about Mythos, and other models like it, is the breadth of knowledge about potential security risks and the speed at which they can adapt to find new security holes. \u201cA friend of mine runs a small security consulting testing company, and he got into Mythos and took some of the penetration scripts that he had trained the tool on, the usage of the scripts, and worked with the tool to find what other zero days already exist,\u201d said Scott Best, senior director for silicon security products at Rambus<\/a>. \u201cThere are very few actual proprietary attacks. But when you train a chatbot on the entirety of the Internet, and all the human knowledge that has ever been online, and then you strip-mine it for the parts, you get a lot of obscure information that you didn\u2019t know about. There is outstanding research out there that nobody knows about, and these tools have been trained on all of it. So my friend had the tool investigate other zero days and compiled it together, and he instrumented a fake network that was completely virtualized, put a bunch of virtual machines on the network running various commercial operating systems, and set this tool loose. And we just watched as the tool ran these scripts and thousands of cybersecurity vulnerabilities and probed every one of them, and something like 20% of those systems were now compromised. This all happened within 10 minutes while sitting in a pub. Mythos is an incredible force multiplier.\u201d<\/p>\n Validation Validation is a good example. In the past, as long as a device met or exceeded the power and performance specs, and was fully functional at time zero, it was considered a good chip \u2014 even if it didn\u2019t turn out exactly as the device\u2019s architect(s) intended. But in an AI world, that\u2019s no longer the case. For security reasons, what comes out of manufacturing increasingly needs to look much more like it was supposed to, and it needs to be validated against different workloads, and at different points in its lifecycle.<\/p>\n \u201cAI introduces some new concepts, like non-deterministic type of aging, meaning there is some accuracy degradation that may become a security vulnerability, not just performance loss,\u201d said Dana Neustadter, senior director of product management for Security IP and Solutions at Synopsys<\/a>. \u201cAI systems make it more important than ever to move from protecting at design time to adapting over time \u2014 over a lifetime, actually \u2014 because for the AI system it\u2019s not about just making sure that the model works correctly. The behavior needs to be consistent over time, so you need some form of more complex cross-layer trust correlation that needs to happen. AI introduces some new concepts that need to be taken into account, specifically for security.\u201d<\/p>\n AI agents add yet another dimension. \u201cAgentic AI changes the hardware problem because workloads become more dynamic, more distributed, and less predictable,\u201d said Noam Brousard, vice president of solutions engineering at proteanTecs<\/a>. \u201cCPUs, accelerators, memory subsystems, fabrics, and interfaces may be exercised in patterns that are hard to model in advance. That has a direct impact on data analytics because the value is no longer just in knowing what the chip looked like at manufacturing test. The value is in correlating real operating behavior with real electrical margin over time.\u201d<\/p>\n In effect, validation becomes a reference point, margin shrinks, and tighter integration is needed between design teams, fabs, and OSATs. That, in turn, requires sharing more data so it can be analyzed over time, because a chip or chiplet or compute cluster is part of a larger system, and AI-driven attacks can find vulnerabilities anywhere in a system.<\/p>\n Sharing data isn\u2019t something that comes easily for the chip industry. Still, the industry may have no choice as penalties are attached to breaches. Under the European Cyber Resilience Act<\/a> (CRA), for example, the EU can impose fines of up to 2.5% of a company\u2019s total revenue, or up to \u20ac15 million, whichever is greater, for failing to comply with regulations involving hardware and software.<\/p>\n \u201cThere was a big lag in terms of security awareness because there was no one date,\u201d said Yan-Taro Clochard, product marketing group director at Secure-IC, a Cadence<\/a> Company. \u201cNobody said, \u2018You have to do it like this. You have to take care of security in a mandatory manner.\u2019 Having regulations pushing players in the industry to think that through is very important. CRA makes it mandatory for the customer to know what their security problem might be, to anticipate the supply chain, to anticipate their operations, and to think about security during a chip\u2019s lifetime. For the security industry at large, this is a good thing, and overall, security for the entire end-to-end supply chain is very good because it forces everybody to think about how sensitive their assets are.\u201d<\/p>\n Achieving that goal may be painful, however. With AI, understanding what went wrong and who\u2019s responsible is a huge challenge when access to data is limited, or when AI agents begin aging in unanticipated ways.<\/p>\n \u201cAgentic CPUs pose a bigger challenge to reliability than classical CPUs,\u201d said proteanTecs\u2019 Brousard. \u201cIn classic CPUs, when a wrong value results, the entire process would be stopped by a built-in boundary such as a memory violation, a checksum error, or a null result, and the system crashes (ie. blue screen, glitch). The system architecture naturally limits how long a wrong value can remain silent before something catches it or breaks. That is why SDC, or silent data corruption, was not always an obvious, easy-to-sell use case for CPU customers. In many CPU environments, customers may say, \u2018If something goes wrong, we usually know pretty quickly.’\u201d<\/p>\n What caused it to go wrong in an AI chip may or may not be a cyberattack, but a failure could well open the door for a side-channel attack. At the same time, closing that door may be significantly easier if what gets manufactured exactly matches what\u2019s in the initial architecture. The architecture provides a baseline for determining how the AI models and agents, which are otherwise opaque, may have drifted.<\/p>\n \u201cThis is about removing hallucinations and giving results based upon the ground truth of the tools themselves,\u201d said Amit Gupta, senior vice president and general manager of the Solido Custom IC and Central AI divisions at Siemens EDA<\/a>. \u201cAnd then, it\u2019s very important to have skills files that are optimized for the tools so that the agent knows, \u2018Okay, the user is asking for this kind of task. These are the tools that I\u2019m going to call to perform this. And the agents aren\u2019t always going to be right, so it\u2019s important to give \u2018verbose mode\u2019 to the engineers to see what the agent is doing. Then the engineer can say, \u2018Hey, wait a second, this isn\u2019t quite what I wanted. You\u2019re going in the wrong direction. Change it over to this and pause things. Tell the agent to take on this new way of working, and then it can go ahead and interrupt.’\u201d<\/p>\n Verbose mode is an option in many programming languages to provide log or reasoning details, such as which tool is called, what steps are being executed, and what queries are being run. \u201cIt\u2019s not a black box that\u2019s just going off and doing something,\u201d Gupta said. \u201cThe engineer can see what\u2019s happening and run the characterization.\u201d<\/p>\n Visibility is a relative term where AI is involved, but the more data that can be provided by and for design teams, the better.<\/p>\n \u201cAn AI model may be smarter than anyone, but it doesn\u2019t necessarily have all the tools,\u201d said Keysight\u2019s Witteman. \u201cIn addition to models, you also need agents, and agents are AI functions that understand how to use a tool. Typically, you combine an AI model with several AI agents that reach out to the physical world. If you want to test something, you connect it to some test equipment, and that test equipment will be connected to AI agents that know how to run those tests, that are connected to an AI model that can generate tests and execute them. So it\u2019s a network of functions with an AI model at the core and AI agents that talk to the physical world. One team tried to build this whole setup with a model and several agents, and they actually ended up with two models. One model does the testing work, and the other model is the supervisor. So I asked them, \u2018What does the supervisor do?\u2019 And the guy who worked on it said, \u2018The supervisor just keeps testing or overseeing the health of the situation. If a product that you\u2019re testing stops responding, then it doesn\u2019t make sense to keep testing it because it doesn\u2019t do anything. So this supervisor is looking at, \u2018Are there still LEDs blinking? Is there still communication happening? Because if it\u2019s not, then something probably has crashed and you need to reboot everything.’\u201d<\/p>\n Attestation
There is no quick fix to this problem, and no one-size-fits-all solution. But there is widespread concern around the globe about how to close security holes and build more resilient hardware. What\u2019s changed is that in an AI-driven world, security is no longer a separate discipline. It is an integral part of every aspect of chip design through manufacturing and beyond that changes the criticality of different steps and processes, and the level at which any potential problems need to be addressed.<\/p>\n
However, determining what caused a failure isn\u2019t always obvious, particularly in the AI world, so some expert sleuthing is needed. Was some anomalous behavior a security breach, or an orchestration failure in a complex system of systems? To find out, engineers may need to start at the beginning. Where and when were the die, IP, AI agents and models, and various interconnects created? What were the initial specs? Was it manufactured correctly, or was it binned as underperforming or running too hot?<\/p>\n