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.
Shared accountability starts at the specification, not at code review
Spec-driven development changes where security decisions live. When access requirements, trust boundaries, and data handling rules are written into the specification, identity and AppSec teams are no longer reviewing separate artefacts with separate assumptions. They are reviewing the same design intent, which makes it easier to catch mismatches between what a feature is allowed to do and what the implementation later tries to do. That matters because security defects often begin as ambiguous requirements rather than broken code.
For this question, the practical issue is ownership of the assumptions, not ownership of the toolchain. Identity teams are usually better placed to validate role models, privilege scope, and authentication and authorisation logic. AppSec is usually better placed to verify whether the implementation follows the approved pattern, whether insecure shortcuts were introduced, and whether the code preserves the intended control. The two functions need a common reference point in the spec so that neither team is forced to infer the other’s intent after development has already started. See NIST SP 800-53 Rev 5 Security and Privacy Controls for a control-oriented view of how design, access, and review obligations are typically separated. In practice, many security teams encounter entitlement drift only after implementation teams have already treated the original access assumption as fixed.
What the split between identity and AppSec looks like in a working spec process
In a healthy spec-driven workflow, the specification becomes the place where security-critical decisions are explicit. That means the document should state who can access the feature, under which role or condition, what data they may see or change, what approval is required for elevated actions, and which identity source or trust rule is authoritative. Identity teams review those statements for correctness and organisational consistency. AppSec then checks whether the feature design and implementation honour those statements without introducing bypasses, excessive privilege, unsafe defaults, or hidden dependencies.
The split is easier to understand if you separate design correctness from implementation assurance. Identity teams are accountable for whether the access model makes sense: whether a role is overbroad, whether a workflow should require step-up verification, whether service-to-service access is justified, and whether exceptions are actually exceptions. AppSec is accountable for whether the code enforces the documented model: whether access control is server-side, whether policy decisions are consistent, whether security-relevant parameters can be manipulated, and whether testing proves the control works in real paths rather than only in happy-path demos.
- Identity owns the accuracy of the entitlement and trust assumptions in the spec.
- AppSec owns the control validation and abuse resistance of the implementation.
- Product or engineering should not be allowed to resolve access questions implicitly in tickets or comments.
- Design reviews should record decisions in a form that can be tested later.
This model is strongest when the spec contains enough detail to be testable but not so much procedural noise that teams stop reading it. Where organisations fail is usually not in the absence of security awareness, but in the absence of a single agreed description of who may do what and why. That guidance breaks down when access logic is heavily dynamic, delegated across systems, or changed late in delivery without re-review.
Where shared accountability gets messy and what to do about it
Tighter shared review often increases coordination overhead, so organisations need to balance speed against the cost of unresolved assumptions. The tradeoff is real: the more dynamic the authorisation model, the more likely teams are to argue about ownership unless the spec makes decision rights explicit.
One common edge case is when the security implication sits in a service boundary rather than in the feature itself. In that case, identity may own the trust relationship, but AppSec still needs to challenge whether the endpoint exposes more than the specification promised. Another edge case is delegated administration: teams sometimes assume that because a platform team defined the directory or policy layer, application teams no longer need to validate how local roles map to that layer. That is usually a mistake. Shared accountability still applies, but the scope of review changes.
Where there is disagreement, the useful question is not which team “owns security” in the abstract. It is which team owns the correctness of the assumption, which team owns the enforcement point, and which team can prove that the assumption remains true after change. That becomes especially important when specifications are reused across multiple teams, because a single ambiguous access statement can replicate the same flaw everywhere it is copied. Guidance-vs-consensus note: there is broad agreement that review should happen early, but less consensus on how much identity detail belongs in the spec versus a linked policy record.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Shared accountability hinges on defining and validating access assumptions. |
| Recommendation — Review and approve access assumptions before implementation to prevent overbroad entitlement scope. | ||
| NIST CSF 2.0 | PR.AA-01 — Identity Management, Authentication, and Access Control | The question centers on identity assumptions and enforcement responsibilities. |
| PR.DS-01 — Data-at-Rest Protection | Spec-driven security must include the data exposure decisions embedded in the design. | |
| GV.RM-01 — Risk Management Roles, Responsibilities, and Authorities | The core issue is how security responsibility is divided across teams. | |
| Recommendation — Define who approves access design and who verifies enforcement for each protected workflow. Document data exposure assumptions in the spec and test that implementation preserves them. Assign explicit security decision owners for design-time access assumptions and implementation checks. | ||
Practitioner Guidance
What to prioritise: Put the access model, privileged workflow, and data exposure decision in the same review thread as the feature spec. If the spec cannot answer who may act, what they may reach, and what changes require re-approval, the accountability split is already too vague to trust.
What to verify: Confirm that identity reviewers are validating the correctness of the role and trust assumptions, not merely approving a label, and that AppSec reviewers are testing the actual enforcement path, not the written intent. The key evidence is traceability from requirement to control to test case.
Common mistake: Treating “shared accountability” as shared ownership of everything. In practice, that usually produces gaps because each team assumes the other is covering the hard part. The better model is shared design accountability with distinct enforcement and correctness responsibilities.
Practitioner takeaway: The safest operating model is one where identity teams can challenge whether the access model is right, AppSec can prove it is enforced, and neither team is left interpreting security intent after development has already frozen the design.
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?
- How should security teams handle AI-driven phishing in identity workflows?
- How should security teams detect identity-driven cyber threats faster?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
