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.
Where shared accountability starts in spec-driven development
Spec-driven development changes the control point. The security decision is not only whether code passes AppSec checks, but whether the specification itself correctly states who can do what, with which data, and under which conditions. Identity teams should review the role model, entitlement boundaries, and privileged paths before implementation hardens around a wrong assumption.
That matters because design errors tend to become durable. If access expectations are buried in a ticket, a user story, or an API contract without explicit review, the implementation may satisfy the spec while still granting too much access or exposing the wrong data. Shared accountability works best when identity and AppSec both sign off on the security intent before build work starts.
Design-time review is also where the team can separate business need from convenience. A good spec makes privilege boundaries visible, defines whether elevation is temporary or standing, and states which data flows are sensitive enough to require extra checks. If those decisions are made early, implementation review becomes validation, not archaeology.
What each team actually owns
AppSec owns the implementation controls: secure coding requirements, testing, release gates, and evidence that the shipped behavior matches the approved spec. Identity owns the correctness of access assumptions: role definitions, entitlement scope, separation of duties, and whether the design reflects the real operating model rather than an idealised one.
The practical boundary is simple. If the question is “does the implementation enforce the intended rule?”, AppSec leads. If the question is “is the intended rule the right access rule in the first place?”, identity leads. The two functions overlap at design review because a flawed access model can be implemented perfectly and still be insecure.
This is where the right operating pattern looks more like joint control than handoff. Security requirements should be written so that entitlement scope, privileged workflows, and data exposure are visible in the same review path as functional acceptance criteria. That lets AppSec test the control and identity test the assumption behind it.
That joint model is consistent with a wider secure development lifecycle approach, where security requirements, design review, and release gates are treated as part of normal delivery rather than a late-stage exception. NHI Management Group’s Secure Software Development Lifecycle (SSDLC) Guide covers that broader control pattern.
How to keep access decisions visible in the specification
The most useful spec is the one that makes access decisions testable. A strong security specification states who may initiate, approve, elevate, view, export, or revoke access, and it links those actions to the specific data or workflow being protected. If the document does not make those boundaries explicit, the review becomes subjective and inconsistent.
Teams should treat entitlement scope as a design artifact, not an implementation afterthought. That means reviewing role names for ambiguity, checking whether a privileged workflow is truly exceptional, and confirming whether the design depends on inherited access that will be difficult to audit later. The goal is not to over-document everything, but to make the security-relevant assumptions visible enough to challenge.
Where the design touches tokens, sessions, federated access, or other identity controls, the spec should also state the security assumption being made, not just the technical mechanism. A control that depends on “only trusted users will reach this path” is weaker than one that states the concrete trust condition and the evidence required to verify it.
Identity and AppSec teams can use a simple review rule: if a security reviewer cannot point to the exact entitlement, role, or privilege rule in the spec, then the rule is not yet review-ready. NHI Management Group’s Security RACI Matrix Template is a useful reference for making ownership and decision points explicit across the delivery flow.
Risk and Threat Considerations
Spec-driven development creates a hidden-risk problem when access logic is embedded in the design but never explicitly validated. The result is usually not an obvious break, but quiet overreach: overly broad roles, privileged workflows that are hard to see, and data exposure rules that differ between intent and implementation.
Failure mechanism: A developer implements the written specification exactly as provided, while the underlying entitlement model is wrong, incomplete, or too permissive. Because the access decision was never challenged at design time, the defect survives review and can be replicated across multiple features or services.
Impact: Excessive access can become normalised in production, making misuse, lateral movement, and data overexposure harder to detect and harder to unwind. When access assumptions are not jointly owned, remediation often requires both code change and role redesign.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, OWASP SAMM and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V8 — Authorization | Spec-driven access rules hinge on role and privilege correctness. |
| Recommendation — Review authorization requirements early and verify the implementation enforces the intended access rule. | ||
| OWASP SAMM | IAM — IAM | Shared accountability depends on security requirements and design review in delivery. |
| Recommendation — Embed access assumptions into security requirements and design reviews before release. | ||
| NIST SP 800-53 Rev 5 | SA-8 — Security and Privacy Engineering Principles | The question is about shared ownership of security decisions during system design. |
| Recommendation — Apply engineering principles that assign security responsibility during design, not after implementation. | ||
Practitioner Guidance
What to verify: Require the spec review to answer three questions before build approval: who needs access, what privileged action they are allowed to take, and what data exposure that action creates. If any of those are implicit, the review is not complete.
Decision rule: If the access rule changes the blast radius of a feature, treat it as a shared design decision and not just an AppSec test case. If the access rule only affects implementation detail, keep AppSec as the owner but still document the identity assumption clearly enough to test.
Practitioner takeaway: Shared accountability works when identity teams own the correctness of access assumptions and AppSec owns the enforcement, with both meeting at design time before those assumptions harden into code.
Related resources from NHI Mgmt Group
- How do identity teams and data security teams share accountability for on-prem exposure?
- How should security teams govern spec-driven development when AI agents consume specs at scale?
- Why does spec-driven development create governance risk once multiple agents and repositories share the same instructions?
- What role does cross-team accountability play in AI-driven identity security?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 5, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org