How should AppSec teams and platform teams share accountability for AI-assisted delivery?

How AppSec and platform teams split accountability without splitting control

AI-assisted delivery works best when AppSec owns the policy intent and the acceptance thresholds, while platform and engineering own the control implementation in the delivery path. That split avoids a common failure mode where security writes rules no one can operationalise, or platform teams automate workflows without clear risk boundaries. The result should be one accountable control chain, not parallel processes.

At a practical level, the shared accountabilities usually center on inventory, ownership, policy enforcement, and evidence capture. AppSec should define which AI-assisted changes are permitted, what evidence is required for release, and which exceptions need review, while platform teams embed those requirements into pipelines, templates, and guardrails. That structure keeps governance close to delivery instead of bolted on after the fact.

Shared accountability also means the two teams need a common definition of "done." If a release can only be approved when the pipeline proves who changed what, what policy checks ran, and what exceptions were granted, then the control is measurable rather than assumed. For AI-assisted delivery, this is especially important because the speed of change can hide weak review practices unless the workflow itself produces trustworthy artefacts.

Where the boundary should sit in day-to-day delivery

The boundary is best drawn by control type, not by team identity. AppSec should own the risk model, minimum control requirements, and escalation criteria for AI-generated or AI-assisted changes. Platform teams should own the automation that enforces those requirements in code review, CI/CD, deployment policy, and release gating. Engineering teams remain accountable for the quality and traceability of the change itself.

That division is strongest when the control is expressed as an enforceable platform policy. For example, if a change touches sensitive code paths or production access flows, the pipeline should require stronger review, reproducible build evidence, or an explicit exception record before it can proceed. OWASP ASVS is useful here because it gives AppSec a concrete way to state what secure authentication, authorization, and verification expectations should look like.

Platform teams should not be asked to guess where security thresholds begin. They need a small number of crisp policy decisions from AppSec, then the engineering task is to make those decisions repeatable in the delivery system. That is the difference between a governance model and a suggestion box.

For teams looking for a maturity lens, OWASP SAMM helps frame this as a software assurance practice rather than a one-off control project. It supports the idea that policy, build integrity, verification, and release assurance are shared disciplines that need clear ownership and continuous improvement.

What good evidence looks like for AI-assisted releases

AI-assisted delivery raises the bar for evidence because reviewers often cannot rely on a human author’s memory alone. Good evidence includes the change origin, the policy checks that executed, the review path taken, and the final release decision. If AI contributed to code, configuration, or test creation, the record should still show the human and system approvals that made the change acceptable.

That evidence should be generated by the pipeline, not assembled manually after the fact. Manual evidence tends to drift, while automated release evidence creates a more consistent audit trail and makes control exceptions visible. NIST SSDF is a strong reference for this because it ties secure development to repeatable practices around provenance, review, and supply-chain integrity.

Teams should also be explicit about ownership metadata. If ownership is unclear, the control chain breaks at the first exception, incident, or hotfix. When a platform team can route a release to the right owner and AppSec can verify the required evidence, accountability becomes operational rather than ceremonial.

Risk and Threat Considerations

AI-assisted delivery can compress decision time faster than review quality improves, which creates risk around unsafe changes, hidden dependencies, and misplaced trust in automated output. The main exposure is not that AI is used, but that no one can clearly prove which controls ran before code or configuration reached production.

Failure mechanism: If ownership, policy checks, and release evidence live in different places, teams can pass responsibility around while a risky change still ships. The gap is especially dangerous when AI-generated changes look plausible enough to bypass normal scrutiny.

Impact: Weak accountability can lead to unauthorised changes, approval drift, incomplete audit trails, and slower incident containment because no team can quickly reconstruct who approved the release and under what conditions.

Practitioner Guidance

What to prioritise: Establish a single control contract for AI-assisted delivery, then decide which parts are policy decisions and which parts must be automated into the pipeline. AppSec should own the thresholds; platform teams should own the enforcement points.

What to verify: Every production path should be able to show who owns the change, what checks ran, what evidence was produced, and how exceptions were approved. If any one of those elements is missing, the control is not yet governable.

Decision rule: If a control cannot be enforced or evidenced in the delivery system, treat it as advisory only until it is embedded. If it can be automated, automate it, because AI-assisted delivery increases the cost of relying on ad hoc human recollection.

Practitioner takeaway: Shared accountability works only when AppSec defines the rules and platform teams make those rules unavoidable in the path to release; otherwise, AI speeds up delivery faster than governance can keep up.

Related resources from NHI Mgmt Group

• How do identity and fraud teams share accountability for delivery-platform abuse?
• How should security teams handle risks from AI browser extensions?
• How should security teams govern API keys used for generative AI access?
• How should teams govern AI-assisted internal app building without slowing delivery?