University of Idaho Chip Security Win Puts AI on Both Sides of the Fight

University of Idaho chip security researchers won first place in a 2026 competition where generative AI served as both defender and attacker. Undergraduate Lloyd Alcorn and Assistant Professor Zain Ul Abideen built a workflow that concealed sensitive chip-design information while testing what an AI-assisted adversary could reconstruct.

That combination creates the real tension. AI can help engineers protect intellectual property inside a design, but the same class of technology can help an attacker interpret the protected files. A defense therefore cannot succeed merely by making a circuit difficult for a person to read.

The project won the GenAI-Guided Hardware IP Redaction and Red-Teaming Challenge at the 63rd Design Automation Conference, known as DAC. The result does not establish a production-ready security standard. It does show how AI chip design security is becoming an adversarial measurement problem, rather than a one-time act of hiding information.

University of Idaho Chip Security Wins at DAC

The winning project treated protected chip design as something that must remain functional while actively resisting reconstruction.

Alcorn, an electrical engineering senior, worked with Abideen during a remote competition that ran from June through July 2026. Awards were presented during DAC, a major conference covering chip design and electronic design automation.

The University of Idaho said the conference brings together more than 5,000 researchers, engineers, industry professionals, and students. Alcorn competed alongside participants from both academia and industry, despite entering as an undergraduate.

Their task involved hardware IP, the reusable logic, architectures, constants, and control structures that give a chip part of its distinctive behavior. This property often appears in register-transfer level code, or RTL, which describes how digital logic processes and transfers data.

Alcorn and Abideen created a security system that obfuscated critical information about a chip’s functionality and intellectual property. Obfuscation changes how a design appears to an observer while preserving its intended behavior.

That second requirement matters. A protection scheme that breaks simulation, integration, timing, or computing performance has little practical value. The team had to hide valuable information without sacrificing the design’s operation.

According to the university’s account of the winning project, Alcorn repeatedly adapted and tested the protection workflow. He verified that protected designs still operated correctly and measured effects on power and timing.

He then conducted an AI-assisted adversarial evaluation. That evaluation asked what information an attacker might still infer from the altered design, rather than assuming that transformed code was automatically secure.

The competition formalized that conflict through blue and red teams. Blue teams concealed sensitive details, while red teams used generative AI to attempt reconstruction, reverse engineering, and auditing.

Organizers described several targets for protection. These included module names, circuit hierarchy, finite-state machine behavior, proprietary constants, cryptographic structures, and sensitive control logic. A red team could then use AI to infer the original roles or relationships.

This is why the award is more significant than a conventional student design prize. The team did not simply ask an AI system to generate a circuit. It worked on the harder boundary between usability and secrecy, then exposed the defense to an intelligent attacker.

Why Hardware IP Redaction Is Getting Harder

Hardware IP redaction now has to survive machines that can reason across code, structure, naming patterns, and circuit behavior.

Traditional redaction often relies on removing descriptive comments, renaming signals, or concealing selected design blocks. Those steps can frustrate casual inspection, but they do not necessarily erase the relationships embedded in a functioning circuit.

A module with anonymous names still has inputs, outputs, timing behavior, and connections. A state machine still moves through patterns. A cryptographic component can retain recognizable constants or data flows after its labels disappear.

Generative AI changes the economics of examining those clues. It can summarize unfamiliar RTL, propose likely module roles, compare repeated structures, and generate hypotheses about missing logic. An attacker still needs technical knowledge, but AI can reduce the cost of exploring many possibilities.

The same capability helps defenders. A security engineer can use an AI-assisted workflow to identify revealing names, locate sensitive logic cones, propose transformations, and review whether those changes preserve intended behavior.

A logic cone is the collection of circuit elements that influence a particular output. If a security-critical output can be traced back to recognizable gates or constants, hiding labels alone may offer weak protection.

The University of Idaho team’s approach reflects this dual use. AI supported the defensive workflow, then helped probe the result from an adversarial perspective. The tool was neither inherently protective nor inherently hostile.

This dynamic is already appearing across the research agenda for electronic design automation. DAC’s 2026 security research agenda explicitly includes AI-based hardware attacks and defenses, reverse engineering, hardware obfuscation, and security-preserving design automation.

The conference also called for work on foundation models for EDA, agentic verification, physical design automation, and benchmarks for evaluating AI systems. EDA refers to the software used to design, simulate, verify, and prepare electronic systems for manufacturing.

Those developments make AI chip design security a moving target. A transformation that defeats one model or prompt strategy might leak information to a stronger model, a specialized agent, or a workflow combining AI with formal analysis.

The threat is also broader than source-code theft. A reconstructed design could reveal proprietary algorithms, security checks, cryptographic structures, or implementation decisions. That information can support counterfeiting, cloning, vulnerability discovery, or malicious modification.

NIST describes the semiconductor supply chain as a network spanning intellectual property, design, manufacturing, testing, packaging, and distribution. Its hardware security program treats IP piracy, reverse engineering, and hardware Trojans as related design-for-trust concerns.

A hardware Trojan is malicious logic added to a circuit to alter behavior, leak information, or create hidden access. Unlike an ordinary software vulnerability, it can become part of the physical device.

Redaction alone cannot stop every such risk. However, the competition addresses an important early stage: limiting what design artifacts reveal when they must move between teams, tools, vendors, or facilities.

That requirement is difficult because semiconductor production is distributed. A design can pass through multiple organizational and technical boundaries before a finished component reaches a product.

Every boundary creates a conflict. Partners need enough information to perform simulation, verification, integration, manufacturing, or testing. The IP owner wants to disclose no more than those tasks require.

Hardware IP redaction tries to manage that conflict. Generative AI makes both sides faster, so protection now needs repeatable adversarial testing rather than confidence based on obscurity.

The Real Contest Was Usability Versus Secrecy

The decisive problem is not whether a design can be hidden, but whether it can remain useful after its most revealing features are removed.

A defender could theoretically make reconstruction impossible by withholding the entire design. That approach also prevents legitimate collaborators from simulating, testing, or integrating it.

Practical protection must preserve an agreed level of utility. A redacted artifact might need to compile, pass functional tests, expose defined interfaces, and meet timing constraints. Each retained capability can also reveal additional information.

This creates a tradeoff similar to data anonymization. Removing obvious identifiers does not guarantee privacy when relationships among the remaining fields can reveal the missing information.

Circuit structure can be equally informative. Inputs, outputs, repeated operations, lookup patterns, and state transitions may identify a component even when its original names and comments have disappeared.

An obfuscation method can add transformations or keyed behavior to make the design harder to interpret. Yet those changes can raise power consumption, extend critical timing paths, increase area, or complicate verification.

The University of Idaho team measured power and timing because security cannot be evaluated in isolation. A defense that imposes an unacceptable implementation penalty will struggle to survive a commercial design review.

DARPA identified the same underlying obstacle in its secure silicon automation program. The agency noted that chip-level security often faces economic hurdles and technical tradeoffs, while late design changes are exceptionally difficult.

Its response was an automated design flow capable of evaluating architectural alternatives against security and implementation goals. That framing closely matches the problem exposed by the DAC challenge, even though the programs are separate.

Automation matters because chip design already involves a vast search space. Engineers balance function, performance, power, area, reliability, verification effort, manufacturing constraints, and delivery schedules.

Security adds another objective, but it cannot simply override every other requirement. A protected design still needs to become a working product.

AI can help explore candidate transformations faster. It can also help an adversary search for patterns that survived those transformations. The resulting contest is iterative, not static.

A blue team changes the design. A red team searches for retained meaning. The blue team then adjusts the transformation, verifies functionality again, and measures any new costs.

That loop resembles modern software security testing, where defenders continuously scan code and attackers continuously search for bypasses. Hardware introduces a harsher constraint because mistakes can persist after fabrication.

A software patch can often be deployed after release. A flawed chip design can require expensive replacement, a new fabrication run, or compensating controls elsewhere in the system.

This makes pre-silicon evaluation especially valuable. Pre-silicon refers to work performed before a design becomes a manufactured chip. AI-assisted testing can probe design artifacts while engineers can still revise them.

The Idaho result therefore supports a mechanism, not a universal answer. Use AI to assist protection, preserve design utility, measure implementation costs, and attack the output before trusting it.

That mechanism can improve engineering discipline even when the model produces imperfect suggestions. It forces the team to define what must remain usable, what must remain secret, and what evidence counts as a successful defense.

AI Chip Design Security Needs Better Evidence

A first-place finish shows competitive success, but it does not yet prove that the workflow can protect commercial semiconductor IP.

The public University of Idaho report does not provide a detailed technical paper, benchmark suite, model inventory, scoring breakdown, or complete threat model. It also does not publish the protected designs or successful reconstruction attempts.

Those omissions are understandable in a short university news story. They still limit what outside engineers can conclude from the result.

A meaningful evaluation must define the attacker’s access. Did the red team receive RTL, a synthesized netlist, simulation outputs, interface documentation, or only selected artifacts? Different access levels create very different reconstruction risks.

The model configuration also matters. A general language model, a code-focused model, and an EDA agent connected to analysis tools may produce different results.

Prompting and iteration can affect performance as well. An attacker with one query does not represent an attacker who can run many agents, compile candidate designs, inspect failures, and refine hypotheses.

Evaluation metrics remain another unresolved issue. A defense might prevent exact source reconstruction while still leaking the component’s purpose, algorithm, constants, or security boundary.

Conversely, an AI system might generate plausible explanations that are technically wrong. Apparent reconstruction is not the same as verified recovery.

A strong benchmark therefore needs several layers of measurement. It should test functional equivalence, structural similarity, semantic inference, secret recovery, and the cost imposed on the protected design.

It should also test whether the defense transfers across unseen circuit families. A method tuned to one benchmark can perform well in competition while failing on different architectures.

NIST has emphasized this measurement gap. Its hardware program calls for reference datasets and metrics that can support testing, attestation, certification, and verification of semiconductor components.

The agency’s 2026 standards workshop report also identified scalable verification and validation as a priority. Recommended approaches included AI-assisted analysis, formal methods, fuzzing, standardized testing, and resilience evaluation.

That combination is important. AI should not become the sole judge of whether AI successfully protected a design.

Formal methods use mathematical reasoning to verify properties about a system. Simulation executes selected scenarios, while formal verification can examine broader classes of possible behavior under defined assumptions.

The most credible AI chip design security workflow would combine model-assisted exploration with deterministic checks. The model can propose transformations or attacks, while conventional tools verify function, timing, power, and security properties.

Reproducibility is equally important. Researchers need records of model versions, prompts, tool calls, intermediate artifacts, and validation results. Otherwise, a winning result can be difficult to compare or repeat.

AI services also create their own confidentiality questions. Uploading proprietary RTL to an external model could expose the very information a protection workflow is meant to secure.

A production deployment would need clear controls over data retention, model access, logs, isolation, and ownership of generated artifacts. Local or organization-controlled models may reduce some exposure, but they do not eliminate technical risk.

There is also a benchmark contamination problem. If public circuit examples appear in model training data, a system might recall familiar patterns rather than infer them from a genuinely protected design.

Researchers must distinguish memorization from reconstruction. Private evaluation circuits, controlled disclosure, and post-training benchmarks can help, although they make open replication harder.

The award is therefore evidence that the approach deserves deeper study. It is not evidence that generative AI has solved hardware IP protection.

Chipmakers Face a New Attack-and-Defense Cycle

The pressure falls on every organization that shares design artifacts beyond a tightly controlled internal team.

That group includes chip companies, reusable IP vendors, foundries, cloud EDA providers, verification contractors, packaging specialists, and research partners. It also includes customers integrating licensed cores into larger systems.

The pressure source is not a single competitor. It is the growing ability of attackers to combine AI reasoning with established reverse-engineering and analysis tools.

Generative models can lower the barrier to examining unfamiliar hardware descriptions. They can translate syntax, explain likely behavior, propose tests, and generate scripts for existing toolchains.

Specialized engineers still matter. Hardware behavior depends on timing, synthesis, physical effects, and implementation details that natural-language output can misrepresent.

However, attackers do not need full automation to gain an advantage. A modest reduction in analysis time can make more targets economically attractive.

Defenders will face pressure to test protected artifacts against evolving model capabilities before sharing them. They will also need to document what information each recipient actually requires.

That moves access control closer to the design itself. Instead of treating every approved partner as entitled to the same artifact, companies can tailor disclosure to a specific task.

The University of Idaho project provides a compact demonstration of this approach. Preserve what a legitimate workflow requires, obscure sensitive information, and challenge the result from an attacker’s perspective.

The wider EDA industry is already moving toward more autonomous systems. DAC’s discussion of an AI-native EDA stack argues that infrastructure, integration, and trust have become central obstacles to production adoption.

Security is part of that trust problem. An agent that can inspect repositories, run tools, modify RTL, and interpret verification results has more capability than an isolated chatbot.

Greater capability helps engineering teams automate difficult work. It also increases the consequences of excessive access, incorrect reasoning, compromised instructions, or poorly protected logs.

Chip organizations will therefore need controls designed for agents, not only human users. Those controls include narrow permissions, isolated workspaces, reproducible tool execution, and review gates before sensitive changes enter a design.

This is where the competition model becomes useful beyond education. Red and blue teams provide a structured way to expose assumptions before an adversary does.

The approach can also strengthen semiconductor education. Students who learn only design optimization may miss how seemingly harmless artifacts reveal proprietary or security-sensitive information.

Abideen said the competition combined generative AI, chip-design tools, and adversarial security analysis in a way rarely available to undergraduates. That combination matters because future engineers will inherit both automated design systems and AI-assisted threats.

The University of Idaho has a broader hardware security foundation behind the project. Abideen’s research covers trustworthy integrated-circuit design, security-aware EDA, reverse-engineering defenses, circuit obfuscation, and AI-assisted chip design.

Still, the most useful lesson is not institutional. It is operational: teams should assume that readable design artifacts will receive increasingly capable automated analysis.

That assumption changes the burden of proof. A defense should not be considered adequate because engineers cannot immediately see through it. It should survive defined attacks, measurable validation, and repeated testing with new tools.

Three Signals Will Show Whether the Win Matters

The next test is whether this competition result develops into reproducible evidence, stronger benchmarks, and adoption beyond a university project.

The first signal is a technical release. A paper, benchmark, repository, or detailed competition report would clarify the threat model, protected artifacts, models, scoring system, and implementation overhead.

If that material shows consistent protection across several unseen designs, it would strengthen the case for AI-assisted hardware IP redaction. If the result depends on one narrow benchmark, the broader claim would weaken.

The second signal is independent red-team performance. Other researchers should test the same protection against different models, agent architectures, and conventional EDA tools.

A defense that survives only the attacks anticipated by its own designers offers limited assurance. A defense that resists independent teams while preserving function provides more meaningful evidence.

The third signal is integration into a repeatable design workflow. Watch for tools that connect redaction, simulation, formal checks, timing analysis, power measurement, and adversarial evaluation.

Integration would show that AI chip design security can operate within real engineering constraints. A standalone demonstration that requires extensive manual tuning would remain useful research, but not yet a scalable production method.

These signals matter more than the award itself. Competitions reward progress under defined rules, while deployed semiconductor security must handle unknown designs, changing attackers, confidentiality controls, and costly errors.

The University of Idaho chip security win still marks an important shift. It places AI on both sides of the same design boundary and measures defense through active attack.

For developers and security teams, the practical question is now concrete: which design artifacts can your organization safely share, and how would you test what an AI-assisted adversary can infer from them? Track the emerging benchmarks, demand reproducible validation, and treat model access as part of the hardware threat model. The organizations that answer those questions before deployment will be better prepared for an attack-and-defense cycle that has already begun.