Who should own threat modeling when AI coding agents are shipping more software?

Ownership should sit with the security and engineering teams together, with agents producing the first-pass model and humans validating the important edges. The model needs to support triage, review, and remediation, but final judgment still belongs to practitioners who understand business risk and deployment reality.

Why This Matters for Security Teams

When AI coding agents can draft code, open pull requests, and suggest fixes, threat modeling stops being a periodic workshop and becomes part of the delivery pipeline. The ownership question matters because the first-pass model may come from the agent, but accountability for the risk decision still sits with the organisation. The NIST AI Risk Management Framework is useful here because it frames AI risk as a governance problem, not just a tooling problem.

Security teams get this wrong when they treat agent output as authoritative, or when engineering assumes security will catch every issue after the fact. A threat model only helps if it is tied to specific code paths, deployment boundaries, and abuse cases that matter in production. With agentic workflows, the risk surface expands to include prompt injection, insecure tool use, secret exposure, and unsafe assumptions made by the model during code generation. In practice, many security teams encounter these failures only after the agent has already shipped risky code into a release branch, rather than through intentional design review.

How It Works in Practice

The most workable pattern is shared ownership with clear division of labour. Engineering owns system context, architecture accuracy, and implementation choices. Security owns threat taxonomy, attacker thinking, and acceptance criteria. AI coding agents can assist by proposing assets, trust boundaries, misuse cases, and likely abuse paths, but humans need to validate the important edges and decide whether a risk is acceptable.

A practical workflow often looks like this:

• Define the system boundary before the agent starts generating design assumptions.
• Have the agent draft a first-pass model from architecture docs, tickets, and repo context.
• Map threats to concrete controls such as code review, secret scanning, sandboxing, and least privilege.
• Use human review for high-impact paths such as authentication, payment logic, data export, and agent tool access.
• Track unresolved risks as backlog items with an owner, due date, and explicit acceptance decision.

For AI-specific threat categories, teams should look at adversarial manipulation of model behaviour and generated code quality. The MITRE ATLAS adversarial AI threat matrix helps structure this analysis, while the OWASP Agentic AI Top 10 and CSA MAESTRO agentic AI threat modeling framework are useful for identifying tool misuse, prompt injection, and untrusted action execution. These controls tend to break down when the agent has broad repo access and direct deployment credentials because the threat model no longer reflects the real privilege boundary.

Common Variations and Edge Cases

Tighter threat modeling often increases delivery overhead, requiring organisations to balance release speed against confidence in the model. That tradeoff becomes sharper when teams use multiple agents, low-code connectors, or autonomous PR creation, because every extra integration widens the path from suggestion to production change.

There is no universal standard for who signs off on agent-generated threat models yet. Current guidance suggests a tiered approach: security owns the method, engineering owns the system detail, and product or platform leadership resolves residual risk when business impact is high. For regulated environments, the bar is higher because model failure can affect auditability, incident response, and software supply chain integrity. The CISA cyber threat advisories are useful for tracking active attacker techniques that should feed into the model, not just theoretical ones.

The edge case is autonomous remediation. If the agent can not only flag a threat but also modify code or configs, then ownership expands to change control, rollback planning, and approval gates. Best practice is evolving here, but the safe position is simple: agents can propose, humans approve, and the organisation retains the final risk decision. That distinction matters most when the agent is operating in a monorepo or shared platform where one change can affect many services at once.

Related resources from NHI Mgmt Group

• Should organisations treat AI coding agents like privileged software identities?
• Who should own policy for AI coding agents in production?
• Who should own governance for auto-run AI coding agents?
• Who should own secret exposure risk when AI coding agents are in use?