Accountability should sit with the engineering organisation that owns the codebase, with architects defining intended structure and delivery teams enforcing it in workflow. Administration privilege may be needed to create and prioritise the architecture rules, but governance should not depend on manual policing. The control works best when ownership is shared across architecture, development, and platform teams.
Why This Matters for Security Teams
Architecture rules only create value when they shape day-to-day engineering decisions, not when they live as documentation that no one operationalises. In mixed human and AI-generated codebases, accountability gets blurry fast: architects define the target state, but delivery teams, platform owners, and security engineers all influence whether the rules are actually enforced. If the control path depends on manual review alone, it will not scale with code generation, parallel delivery, or fast-moving refactors.
This is why security teams increasingly treat architecture enforcement as a workflow and policy problem, not a committee problem. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls supports defined control ownership, while NHIMG research on the State of Secrets in AppSec shows how gaps between intended practice and developer behaviour are already common in adjacent controls. In practice, many security teams encounter architecture drift only after code has shipped and exceptions have already become the norm.
How It Works in Practice
The most durable model is shared accountability with clear separation of duties. Architecture sets the rules, engineering owns adherence, and platform or DevEx teams embed those rules into tooling so compliance happens inside the delivery flow. For human-written code, that often means linters, code scanning, pull request checks, golden path templates, and repository policies. For AI-generated code, the same rules must be enforced on the output, because the source of the code does not change the target architecture requirement.
Operationally, this works best when rules are expressed as machine-checkable policy and tied to the code review and build pipeline. That means:
- Architects define standards for layering, dependency direction, approved libraries, and secrets handling.
- Delivery teams implement enforcement in CI/CD, pre-merge checks, and scaffolding templates.
- Security or platform teams maintain exceptions, telemetry, and escalation paths.
- AI coding tools are constrained with the same policy, so generated code is not exempt from review.
For policy structure, the current guidance from OWASP and NIST-adjacent control thinking is that rules should be preventive where possible and detectable where not. NHIMG’s DeepSeek breach coverage is a reminder that code and model workflows can expose secrets and sensitive patterns quickly when guardrails are weak. The practical test is simple: if a rule cannot be enforced automatically in the development path, it will become a best-effort expectation instead of a control. These controls tend to break down in highly federated engineering environments because local teams can override central standards faster than governance can review exceptions.
Common Variations and Edge Cases
Tighter architectural enforcement often increases delivery overhead, requiring organisations to balance speed against consistency. That tradeoff becomes more visible when AI tools generate code at scale, because volume rises faster than human review capacity. The answer is not to weaken accountability, but to calibrate it.
There is no universal standard for this yet, but current guidance suggests a few common patterns. In regulated systems, accountability may sit with the product engineering leader while the security architecture function approves control intent. In platform-heavy organisations, the platform team may own the guardrails and the application team owns exceptions. In very small teams, one role may cover both, but the control still needs a named owner and a measurable enforcement mechanism.
The edge case is autonomous or semi-autonomous coding agents. When code is produced by an AI assistant, the responsible human is still the engineering owner of the system, but the governance model must include prompt controls, output scanning, and approval gates. In other words, authorship can be delegated, but accountability cannot. Where teams rely on ad hoc reviews, architecture rules usually fail first in generated boilerplate, then in rushed hotfixes, and finally in the exceptions that were never formally tracked.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OV-01 | Governance oversight fits the need for named ownership of architecture enforcement. |
| NIST SP 800-53 Rev 5 | CM-2 | Baseline configuration control supports enforcing architecture rules consistently. |
| OWASP Non-Human Identity Top 10 | NHI-04 | Rule enforcement for code and AI workflows must cover secrets and identity misuse. |
| OWASP Agentic AI Top 10 | AI-01 | AI-generated code needs governance on outputs, not just human intent. |
| NIST AI RMF | AI RMF governs accountability and operational oversight for AI-assisted workflows. |
Assign a clear control owner for architecture enforcement and review outcomes on a recurring cadence.
