Topic starter
06/11/2026 6:37 pm
TL;DR: Coding agents now shape production automations that handle credentials, so threat models have to move into pull requests and CI to keep security assumptions current as code changes, according to Serval. Security reasoning becomes part of the development workflow, not a separate review artifact.
Editorial analysis by NHI Mgmt Group, based on content published by Serval: “Agentic Threat Modeling: Shipping secure code at machine speed”.
Key questions
Q: How should security teams keep threat models current in fast-changing application environments?
A: Security teams should generate threat models from the code and architecture as they exist now, then refresh them as repositories change.
Q: How do security invariants help validate AI-assisted development?
A: Security invariants are fixed control rules that must remain true as code changes, such as no hard-coded secrets, least-privilege API access, signed dependencies, and approved data flows.
Q: What is the best way to review credential-related changes in automation code?
A: Review credential-related changes by treating them as security-sensitive diffs and requiring a second human approver for any new secret, token scope, certificate, rotation logic, or secret store reference.
Practitioner guidance
- Embed threat models in pull requests Require material changes to trust boundaries, authentication paths, or credential handling to include an updated model in the same change set.
- Define checkable security invariants Convert recurring review requirements into deterministic rules for asset coverage, control references, and justified exceptions so machines can validate them consistently.
- Gate agent-generated changes with CI validation Run model validation alongside tests and static analysis so coding agents receive immediate failure feedback before a reviewer sees the pull request.
Bottom line: Coding agents compress the time between implementation change and security impact, which makes stale threat models a governance risk.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
06/11/2026 6:42 pm
Threat modelling breaks down when security assumptions are treated as separate from the code change. The moment a pull request alters credentials, trust boundaries, or access paths, the model itself becomes part of the system under change. If the model lives outside the workflow, reviewers are forced to reconstruct context after the fact, which is where governance debt accumulates.
A few things that frame the scale:
- 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: How do pull request checks reduce risk from coding agents?
A: Pull request checks reduce risk from coding agents by blocking unsafe changes before merge, including secret exposure, overbroad permissions, unsafe dependency updates, and unauthorised data access. They work best when combined with automated tests, policy checks, and validation runs in CI so generated code must prove it satisfies security rules before it reaches the main branch.
👉 Read our full editorial: Threat models must travel with code as coding agents ship changes