Spec-driven development security is now the new attack surface

At a glance

What this is: Pixee argues that spec-driven development makes the specification, not the code, the security artifact that most determines shipped behaviour.

Why it matters: IAM and AppSec teams need to govern the decisions embedded in tickets, design docs and prompts, because AI-generated code will fill in missing access and data-handling choices on its own.

Context

Spec-driven development is the point at which written intent, rather than source code, becomes the main driver of what gets shipped. That changes the security control point: the most important decisions are now made before implementation, in tickets, design docs and prompts, where access scope, data exposure and audit expectations are often left implicit.

For IAM, PAM and application security teams, this is a governance problem as much as a software problem. When agents infer roles, fields and trust boundaries from incomplete specifications, the resulting behaviour can create unauthorised access paths or expose data without any obvious code-level warning. The issue is typical, not exceptional, in teams adopting AI-assisted development.

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. That creates insecure behaviour that still looks compliant at the code level. The failure is not only technical. It is a governance gap where the real policy was never written down.

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. That can produce direct object access, weak filtering, or missing authorisation checks, which later become real breaches when application logic is reused in production. The risk is strongest around data-rich and admin-facing flows.

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. Code scanning remains useful, but it must sit beside design review and threat modelling rather than replace them.

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.

Technical breakdown

Why the spec becomes the system of record

In spec-driven development, the ticket, PRD or design document is no longer just planning material. It becomes the highest-level description of intent from which code is generated. That matters because code is a lossy projection of the decisions made upstream. When the spec omits role definitions, data scope, logging expectations or boundary checks, the agent has to infer them, and inference is not governance. The result is that security defects can be introduced without any explicit insecure line of code. The primary control point shifts from code review to intent review.

Practical implication: move security review upstream to the specification, where role scope, data handling and audit requirements can still be changed.

How AI agents turn ambiguity into shipped behaviour

AI coding agents do not merely translate intent into syntax. They resolve unanswered questions using patterns from training data and surrounding code. If a ticket says users can export account activity, the agent may decide what a user is, which fields count as activity, and whether the export should include PII or session metadata. That is a control failure only if the organisation assumes the spec already answered those questions. In practice, the agent is filling governance gaps, not just writing code. This creates a new class of security debt: ambiguity debt.

Practical implication: require explicit decisions for roles, fields, tenant boundaries and logging before generation begins.

Why scanners miss intent failures

Traditional code scanners inspect implementation artefacts, not the decision process behind them. A SAST tool can identify unsafe string construction, but it cannot know whether granting a broader role or omitting an audit event violated the approved security model. That is why passing tests and clean scans can still coexist with insecure behaviour. The deeper risk is that the implementation is consistent with the spec, yet the spec itself is incomplete. Effective security therefore depends on validating both the code and the assumptions that produced it.

Practical implication: pair code scanning with specification review and compare shipped behaviour against the intended control boundaries.

Threat narrative

Attacker objective: The objective is to exploit ambiguity in the specification so insecure behaviour ships as if it were approved intent.

1. Entry begins when a developer or product team provides a ticket, PRD or design doc that omits security-critical decisions.
2. Credential or privilege exposure emerges when the coding agent infers access scope, role membership or data fields from surrounding context instead of explicit policy.
3. Impact occurs when the generated feature ships with unintended authorisation, data exposure or missing audit behaviour that no code scanner flagged.

NHI Mgmt Group analysis

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.

Access control must move upstream when code is generated from intent: role definitions, tenant boundaries and data-class rules need to be decided before the agent writes implementation. In IAM terms, this is a shift from reviewing access after the fact to governing access at decision time. Practitioners should treat the spec as the authoritative security artefact.

Security tooling needs a new validation layer between design and code: scanners remain useful, but they are no longer sufficient on their own. The gap is now between approved intent and generated behaviour, so control design has to include intent checks, not just static analysis. That aligns naturally with broader secure SDLC and change-governance practices.

Spec review is becoming the new threat modelling choke point: if the threat model is not regenerated from the current design intent, it will drift from the code the moment an agent fills in missing assumptions. This is especially relevant where human identity, NHI-style service access and agentic behaviour converge in one workflow. Practitioners should assume intent drift is a standing risk, not an edge case.

What this signals

Ambiguity debt will become a recurring AppSec issue: the less explicit the spec, the more security decisions shift into the model's inference layer. That means teams will need design-stage controls that can review roles, data classes and trust boundaries before implementation. In practice, the governance question is no longer whether the code scans cleanly, but whether the intent was ever precise enough to be safe.

As AI-assisted delivery expands, IAM and AppSec teams should expect more security defects to originate in upstream product language rather than in source code. That changes operating rhythm for review boards, because the most effective control is now the one that catches silent assumptions before the agent turns them into behaviour.

For practitioners

• 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.
• Separate generation from validation Make sure the same agent or workflow does not both produce the code and certify its security assumptions.

Key takeaways

• AI-generated code moves the real security risk upstream into the specification, where missing decisions become executable assumptions.
• Scanners can still catch implementation defects, but they cannot detect security intent that was never stated in the first place.
• Teams need review processes that validate design intent, regenerate threat context and compare shipped behaviour to the approved security model.

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.
• Intent Drift: A mismatch between the original purpose of an agent session and the outcome produced by a later chain of actions. It matters because each step can be individually permitted while the overall behaviour still becomes unsafe or non-compliant.
• Ambiguity debt: Security risk created by leaving important decisions unstated in a specification. The more unresolved the design, the more an AI system must infer access, data scope and logging choices, which turns uncertainty into operational behaviour.
• Threat-model regeneration: The practice of rebuilding the threat model from the current design or code state rather than treating it as a static document. This matters when AI-driven changes move quickly, because exposure, trust boundaries and data paths can change with each iteration.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is suitable for teams that need to govern machine identities, access decisions and AI-driven workflows across the wider security programme.