AI-generated code is already shipping in embedded systems - here's how teams are making it safe
AI in embedded development has moved from trial to normal. Teams are now pushing AI-generated code into devices that run power grids, medical equipment, vehicles, and factory lines.
The message is clear: this isn't a side project anymore. It's part of the daily workflow, with few holdouts and growing commitments.
AI adoption: from experiment to routine
Most teams use AI for development tasks, and the rest are actively evaluating it. About half describe their integration as moderate, and more than a quarter report extensive use.
There are almost no avoiders left. That shift signals comfort with AI output and repeatable processes to put it into real products.
Where AI fits best today
Testing and validation lead usage, cited most often by teams. Code generation follows, with deployment automation and documentation close behind.
Security scanning is used less often, which hints at a gap between speed and assurance. Cross-functional patterns are common: product explores requirements, engineers integrate code into firmware, security speeds up scanning.
Production deployments are already here
Most organizations have shipped AI-generated code to production, either widely or in limited cases. Nearly half have deployed it across multiple systems.
Expect more of it. The large majority plan to increase use over the next two years, with many predicting significant growth.
Security concerns are focused on AI-generated code
Security is the top concern, followed by debugging, maintainability, regulatory uncertainty, and the reuse of unsafe patterns. Most teams rate the cybersecurity risk of AI-generated code as moderate or higher.
Confidence in detection is high, with nearly all saying current tools can find issues. Still, about one third of organizations had a cyber incident involving embedded software in the past year, a reminder that faster cycles and more code expand the attack surface.
Runtime defenses take center stage
Runtime monitoring and exploit mitigation are becoming default items, especially when shipping AI-generated code. Memory safety remains the sticking point; most embedded vulns are memory-related.
Many teams still rely on C/C++, and AI trained on legacy code can repeat the same patterns. That's driving demand for runtime controls to contain impact when bugs slip through.
Layered security beats single fixes
High performers combine dynamic testing, runtime monitoring, static analysis, manual review, and external audits. Manual patching is still common and slows response in large fleets.
Runtime exploit mitigations help bridge that gap, limiting exploit paths while patches roll out. Another wrinkle: AI-generated code is often more unique, which reduces the benefit of shared fixes across products.
Regulation is fragmented and lagging
Automotive teams align to sector standards, while industrial and energy groups pull from a mix of frameworks and government guidance. Many standards were written before AI-assisted development, so internal rules are filling in.
For reference models, see NIST's Secure Software Development Framework SP 800-218 (SSDF). For common bug classes (including memory safety), review the MITRE CWE Top 25.
Budgets are following the risk
Most organizations plan to increase security spend for embedded software. Priorities line up with pain points: automated code analysis, AI-assisted threat modeling, and runtime exploit mitigation.
AI increases code volume and adds new patterns. Security leaders are answering with automation and always-on controls.
What effective teams are doing right now
- Put guardrails on code generation: define approved AI tools, data sharing limits, and license policies. Log prompts, outputs, and decisions for auditability.
- Shift-left with automation: SAST, SCA, and fuzzing on every commit; require unit/integ tests for AI-written code before merge.
- Treat memory safety as non-negotiable: prefer memory-safe languages (where feasible) and enforce safe subsets for C/C++; ban unsafe APIs; add sanitizer builds in CI.
- Harden at runtime: enable ASLR, DEP/NX, stack canaries, CFI, W^X, and MTE (where available). Ship with monitoring, anomaly alerts, and feature flags/kill switches.
- Gate releases: threat model changes (AI-assisted is fine), require two-party review for AI code, and fail builds on new high/critical findings.
- Secure the supply chain: SBOMs, reproducible builds, signed artifacts, and continuous dependency scanning; isolate untrusted build steps.
- Close the loop: collect telemetry, triage crashes automatically, and feed findings back into prompts and policies to improve future outputs.
Tooling and upskilling
Pick tools that integrate directly into your existing CI and hardware targets. Favor solutions that provide explainable findings, not just red marks.
If you're evaluating code-gen options, compare capabilities and governance features side by side: AI tools for generative code.
Bottom line
AI is now part of how embedded software gets built, tested, and shipped. The winning pattern is simple: automate detection, strengthen runtime, and set clear rules for how AI code enters your stack.
"AI will transform embedded systems development with teams deploying AI-generated code at scale across critical infrastructure, and we see this trend accelerating," said Joseph M. Saunders, CEO of RunSafe Security.
Your membership also unlocks:
