A workflow where an AI agent converts design assets into application code by reading layout, style, and annotation data. This can accelerate delivery, but it also means the design environment becomes a source of executable context. Security teams should treat the underlying design files as production adjacent data.
Expanded Definition
A design-to-code workflow is an AI-assisted pipeline that turns design system artifacts, layout metadata, annotations, and component references into executable application code. In NHI security, the key issue is not only code generation quality, but whether the design environment is treated as trusted source material that can influence runtime behavior. That makes the workflow adjacent to identity, secrets, and software supply chain controls, especially when the agent can read tokens, tokens-like placeholders, API-linked annotations, or embedded component instructions. Guidance varies across vendors, but the security baseline should map the workflow to least privilege, provenance, and review controls described in NIST SP 800-53 Rev 5 Security and Privacy Controls. NHI Management Group treats the design source as production-adjacent because the agent is effectively consuming authoritative context that can shape deployable output. The most common misapplication is assuming design files are harmless collaboration assets, which occurs when teams allow broad edit access while the agent can also ingest hidden annotations or linked resources.
Examples and Use Cases
Implementing design-to-code rigorously often introduces a tradeoff between delivery speed and the need to inspect design inputs for hidden execution context, requiring teams to weigh automation gains against tighter governance.
- A product team uses an AI agent to convert Figma-like layouts into React components, while security enforces read-only access to approved design libraries and blocks access to design comments containing deployment hints.
- An internal platform team generates boilerplate UI from a design system, then validates the output against NIST SP 800-53 Rev 5 Security and Privacy Controls to ensure review, change control, and traceability are preserved.
- A release engineer investigates an incident after a compromised design plugin injects malicious instructions into exported code, similar in pattern to the supply chain concerns discussed in GitHub Action tj-actions Supply Chain Attack.
- A secure design operations team classifies tokens, API keys, and integration links inside design artifacts as secrets-adjacent data and routes them through review before any AI agent can process the file.
These patterns are common where design systems are mature enough to encode reusable components, but they are also still evolving across vendors and toolchains.
Why It Matters in NHI Security
Design-to-code becomes an NHI security issue when the agent that generates code inherits authority from the design workspace without equivalent guardrails. If a design file contains embedded instructions, linked previews, or references to backend services, the agent may turn non-executable context into deployed behavior. That is why NHI Management Group emphasizes production-adjacent handling for these files, especially because 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to NHI Mgmt Group. The risk is amplified when the workflow crosses into agentic automation, where the same system that reads design intent also writes implementation artifacts, making provenance and access boundaries hard to separate. This is consistent with the control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls and the broader lessons from GitHub Action tj-actions Supply Chain Attack. Organisations typically encounter the security impact only after a poisoned design asset has already influenced generated code, at which point design-to-code governance becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Design artifacts can expose or influence secret handling, fitting improper secret management concerns. |
| OWASP Agentic AI Top 10 | A-03 | AI agents that transform design assets into code need strong input provenance and tool-use controls. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access is central when agents read design systems and produce deployable code. |
| NIST Zero Trust (SP 800-207) | SC-7 | Design-to-code pipelines benefit from segmented trust boundaries and explicit verification of inputs. |
| NIST SP 800-63 | IAL2 | Strong identity assurance helps govern who can alter design inputs that affect code generation. |
Classify design assets as production-adjacent and restrict any embedded secrets or secret-like data from agent access.
Related resources from NHI Mgmt Group
- How should organisations respond when a secret is exposed in code or a workflow?
- Why do autonomous code factories complicate least-privilege design?
- Why do low-code workflow platforms increase identity governance risk around signing?
- What breaks when a workflow engine can execute untrusted code inside the same environment that stores secrets?
