Topic starter
07/09/2026 4:38 pm
TL;DR: When AI writes code from tickets, PRDs, and design docs, the spec becomes the primary security artifact and the attack surface shifts to whatever was never explicitly decided, according to Pixee. That changes how teams review intent, regenerate threat models, and catch assumption drift before it ships.
Editorial analysis by NHI Mgmt Group, based on content published by Pixee: “The Spec Is the New Attack Surface”.
Key questions
Q: What breaks when security decisions are left out of AI-generated specs?
A: Missing decisions become the agent's defaults, which means role scope, data handling and audit behaviour may be inferred rather than approved.
Q: Why do AI coding assistants create access control risk in applications?
A: Because they often generate code that assumes the caller is trusted or that sensitive fields are safe to expose.
Q: How should teams validate generated code against the intended security model?
A: They should compare the shipped behaviour with the approved intent, then check where the implementation added access, data handling or trust assumptions not explicitly authorised.
Practitioner guidance
- Review security decisions at spec time Require explicit sign-off on roles, data fields, audit expectations and tenant boundaries before code generation begins.
- Regenerate threat models from current designs Tie threat modelling to the live spec or diff description so the model reflects current trust boundaries and data exposure.
- Compare shipped behaviour to approved intent Establish a review step that checks whether the implemented feature matches the security promises made in the ticket or design doc.
Bottom line: AI-generated code moves the real security risk upstream into the specification, where missing decisions become executable assumptions.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
07/09/2026 4:38 pm
Spec-driven development creates ambiguity debt: the missing security decisions in a specification become the agent's decision space. That is a governance failure, not just a coding weakness, because the system is now executing unresolved policy. Teams that still treat tickets as informal planning notes are already leaving security control points outside review.
A question worth separating out:
Q: When should organisations treat a design document as a security control?
A: As soon as code is generated from it. At that point, the design document is shaping authorisation, data exposure and logging decisions that would previously have lived in code review. Teams should treat it as a governed security artefact, not a loose collaboration note.
👉 Read our full editorial: Spec-driven development security is now the new attack surface