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.
At a glance
What this is: This is an analysis of how AI-assisted development shifts security risk from code quality to the undocumented assumptions embedded in specs and tickets.
Why it matters: It matters because IAM, AppSec, and platform teams increasingly need to govern who can define behaviour, not just who can deploy code.
By the numbers:
- 90% of developers report using AI coding tools daily.
- Critical vulnerabilities rose about 37.6% after five rounds of iterative AI code generation.
- On BaxBench, secure and correct backends were produced only about 37% of the time.
👉 Read Pixee's analysis of spec-driven development security and AI-generated code
Context
Spec-driven development security starts with a simple governance gap: when AI generates code from tickets, PRDs, or design docs, the specification becomes the real source of truth and the code becomes a downstream projection of that intent. The risk is not limited to application security. It also affects identity and access decisions whenever the spec defines roles, data exposure, audit behaviour, or trust boundaries without explicit review.
That matters for IAM and NHI practitioners because modern delivery pipelines increasingly automate decisions that used to be made by an engineer reading the code closely. If the spec leaves an access rule, data classification, or audit requirement ambiguous, the agent fills in the blanks. The result is a governance problem as much as a coding problem, and teams that only inspect finished code will keep missing it.
Key questions
Q: How should security teams govern AI-generated code in production environments?
A: Security teams should treat AI-generated code as normal production code with extra provenance risk. Require architectural review, test coverage, static analysis, and approval before merge. Then bind the agent and the build pipeline to least privilege, short-lived credentials, and complete audit logging so implementation speed does not outrun control.
Q: Why do AI coding tools create a security risk even when code looks correct?
A: They optimise for syntax and pattern completion, not contextual security reasoning. Code can compile, satisfy tests, and still mishandle input, logging, or trust boundaries in ways that create exploitable flaws. That is why functional correctness and security correctness must be measured separately in governed pipelines.
Q: What are the signs that a specification has drifted away from the security it promised?
A: Look for shipped features that expose more data than the ticket named, broaden roles beyond the original intent, or omit audit events that the design assumed would exist. Those are signs that the spec and implementation no longer match. A reconciliation control should flag that mismatch before release.
Q: How do identity and AppSec teams share accountability for spec-driven development security?
A: AppSec owns the control checks on the implementation, but identity teams own the correctness of role and access assumptions embedded in the design. The strongest model is shared accountability at design time, where entitlement scope, privileged workflows, and data exposure are reviewed together. That prevents access decisions from being hidden inside a development ticket.
Technical breakdown
Why the spec becomes the security artifact
In AI-assisted development, the spec is no longer a planning note. It is the artifact the system uses to decide what to build, which roles can do what, and which data fields are in scope. A ticket, PRD, or design doc can therefore encode access control assumptions, audit expectations, and privacy boundaries without anyone treating them as security requirements. That is why the security failure shifts upstream: the dangerous decision is often made before a line of code exists.
Practical implication: review design artifacts with the same discipline you apply to privileged changes and identity policy.
How agents turn ambiguity into shipped behaviour
An AI coding system does not pause to ask the clarifying questions a careful developer would ask. It infers missing details from surrounding code and training patterns, which means ambiguous roles, loose tenant checks, and vague data scopes become executable behaviour. If the spec says a manager can export data, the agent may generalise that into broader access, omit audit logging, or expose fields that were never named. The issue is not malicious intent. It is ungoverned interpretation.
Practical implication: force explicit decisions on role scope, data fields, and audit requirements before generation starts.
Why scanners miss intent drift
Traditional scanners inspect code paths, not the security promise behind the change. They can flag injection, insecure libraries, or exposed endpoints, but they cannot determine whether the implementation drifted from a ticket’s intended access boundary. That creates a blind spot where the code passes tests, the scanner stays quiet, and the product still ships with a policy mismatch. The deeper failure is the absence of a control that compares intent, design, and implementation as separate artefacts.
Practical implication: pair code scanning with intent review and change-to-spec reconciliation.
NHI Mgmt Group analysis
Spec-driven development security is now a governance discipline, not just an AppSec concern. When AI turns intent documents into code, the specification inherits the burden of defining access, data handling, and audit expectations. That makes the spec a control surface that belongs in both secure development and identity governance conversations. Teams that only validate delivered code are reviewing the wrong artefact. The practitioner conclusion is clear: govern the intent layer or keep discovering policy drift after release.
Identity decisions are increasingly being made before identity teams see them. A ticket that casually labels someone an admin, manager, or approver can expand access in ways that traditional code review will not challenge. That is a real intersection between application delivery and IAM, because the spec can silently define role scope, entitlements, and data reach. The practitioner conclusion is that identity review must move into design-time workflows, not remain an after-the-fact approval step.
Assumption drift is the named failure mode here. The risk is not simply that AI writes insecure code, but that it converts unspoken assumptions into shipped behaviour with no independent check. That is a governance gap across SDLC, IAM, and privacy controls because the system optimises for plausible completion, not policy fidelity. The practitioner conclusion is to treat every ambiguous requirement as a control failure waiting to happen.
Design-stage threat modelling becomes more valuable when code generation is cheap. If code can be rewritten quickly, the durable security signal is whether the intended behaviour was tested before implementation and compared after merge. That aligns closely with NIST CSF governance and secure change control thinking, and it also supports identity control validation where access scope, auditability, and data exposure are concerned. The practitioner conclusion is to make design review and post-change validation a single control loop.
AI-assisted delivery increases the need for separate create, validate, and approve functions. When the same system can draft code, tests, and remediation logic, shared blind spots become a structural problem. Independent review is no longer a process luxury. It is the only practical way to catch policy errors that a model can reproduce consistently but incorrectly. The practitioner conclusion is to separate authorship from assurance wherever access or sensitive data is involved.
What this signals
Spec-driven development will push more security decisions into upstream planning, which means teams need a control that evaluates intent before implementation. The practical shift is toward design review, access rule validation, and live reconciliation between approved requirements and shipped behaviour.
Assumption drift: when AI fills in missing security requirements, the issue is not just code quality but policy fidelity. That is why the most mature programmes will treat tickets, PRDs, and design docs as governed artefacts and connect them to identity, audit, and change control checks.
For teams with strong IAM or NHI oversight, the next step is to extend those controls into delivery pipelines where permissions, exports, and service interactions are first described. See also 52 NHI Breaches Analysis for how small access decisions become broad compromise patterns.
For practitioners
- Review specifications for security decisions before code generation Treat tickets, PRDs, and design docs as security artefacts. Require explicit statements for role scope, tenant boundaries, audit logging, and sensitive data handling before an AI coding system is allowed to implement the change.
- Add identity review to design-time workflows Bring IAM or security architecture into the first review of new features that touch permissions, export functions, or privileged workflows. Catch access expansion in the spec rather than after the code merges.
- Compare shipped behaviour against approved intent Create a control that reconciles the final implementation with the approved specification so that missing tenant checks, broader data exposure, or absent audit events surface as findings instead of incidents.
- Keep threat models tied to the live codebase Regenerate threat models as the application changes so the review reflects current trust boundaries, exposed data, and identity dependencies rather than a stale design snapshot.
Key takeaways
- AI-assisted development shifts security risk upstream, because the spec now drives the behaviour that used to be discovered in code review.
- The core failure mode is assumption drift, where ambiguous requirements become broader access, missing audit, or unintended data exposure.
- The practical response is to govern design-time intent, reconcile it with implementation, and bring identity review into the SDLC earlier.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 | The article is about governing risk created by AI-assisted development decisions. |
| Recommendation — Add design-spec review and intent reconciliation to your risk management process. | ||
| NIST SP 800-53 Rev 5 | SA-8 | Security engineering and design review are central to catching spec drift early. |
| Recommendation — Use SA-8 to require security review of requirements before code generation begins. | ||
| CIS Controls v8 | CIS-16 , Application Software Security | The topic sits inside secure application development and release governance. |
| Recommendation — Embed specification review and validation into application security processes. | ||
| MITRE ATT&CK | TA0007 , Discovery; TA0009 , Collection | The article describes how exposed data and access assumptions become exploitable behaviour. |
| Recommendation — Map code-generation risk to discovery and collection paths when specs expose data or roles. | ||
Key terms
- Spec-driven Development: Spec-driven development is a workflow that starts with written requirements, acceptance criteria, and design boundaries before code is produced. It reduces ambiguity for human engineers and AI tools by turning vague intent into a controlled implementation path.
- Assumption Drift: The gap that appears when the system implements a plausible version of the requirement rather than the security intent the team meant to express. It often shows up as broader access, missing logging, or overexposed data, and it is especially dangerous when automated generation speeds up delivery.
- Intent Reconciliation: A control process that compares the approved specification with the shipped implementation to identify where behaviour has diverged. It is valuable when AI or automation can translate vague requirements into code faster than humans can review every downstream consequence.
- Design-Time Threat Modelling: Threat modelling performed while a feature is still a requirement or design, rather than after implementation. This approach helps teams see trust boundaries, data sensitivity, and identity implications early enough to shape the build, not just inspect it.
What's in the full article
Pixee's full article covers the operational detail this post intentionally leaves for the source:
- The concrete Foresight workflow for reading PRDs, tickets, and diff descriptions before code exists
- Examples of how design-time threat models are generated from the live codebase and kept current
- The way Pixee connects reactive triage with design-stage review in a single context graph
- The CSV export example showing which questions the source article uses to surface hidden assumptions
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, identity lifecycle, machine identity security, and secrets management. It helps practitioners align identity controls with the delivery processes that now shape software behaviour.
Published by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
