How should security teams keep software assurance up with AI coding agents?

What is the main question?

How can organizations safely absorb software changes at the rate AI coding agents can generate them?

What else should teams answer?

• What is assurance throughput?
• Why do AI coding agents change software delivery risk?
• Which checks should run before code can be merged?
• Which changes still need human review?
• Can one AI agent verify another AI agent's work?
• What evidence should be retained for agent-generated changes?
• How can organizations increase assurance capacity without creating a review bottleneck?
• What should be monitored after release?

What assurance throughput means

AI coding agents can increase the volume and speed of software changes. Organizations therefore need to increase the capacity of testing, security checks, review, approval, evidence generation, staged release, monitoring, and rollback at the same time. The practical control model is bounded agent permissions, small and attributable changes, automated merge requirements, tests derived from requirements and risk, risk-based human approval, trusted builds, software supply-chain evidence, staged deployment, production monitoring, and rapid rollback. The goal is justified confidence and usable evidence. Complete certainty is not achievable.

AI Security Hunt uses assurance throughput as an operating concept: the rate at which an organization can establish, with appropriate evidence, that software changes are functional, secure, authorized, traceable, and recoverable. It measures completed assurance decisions, not scan volume. Many checks do not help if results are noisy, ignored, or disconnected from release decisions.

Assurance includes functional quality, security, architecture, authorization, traceability, operational readiness, and reversibility. The appropriate level depends on the risk of the change. Code-generation throughput is how quickly changes are proposed. Assurance throughput is how quickly those changes can be evaluated and accepted, rejected, or revised. Deployment throughput is how quickly approved changes reach an environment. These rates may differ and should be measured separately.

Why AI coding agents create a capacity problem

Software delivery historically had a practical rate limit because people needed time to understand requirements, write code, create tests, debug changes, prepare reviews, and respond to feedback. Testing, architecture review, security review, approval, and release processes could often absorb that flow, even when standards varied.

AI coding agents can create several changes in parallel, produce implementation and tests together, modify application code, configuration, infrastructure definitions, and database changes, add dependencies, generate fixes quickly, and continue across multiple tasks with limited pauses. Faster generation does not automatically increase reviewer attention, test environments, security analysis, architecture review, business understanding, approval quality, or production observation.

The resulting problem is a capacity mismatch. Software changes can be generated faster than the organization can establish that those changes are functional, secure, authorized, traceable, and ready for production. Blanket restrictions may reduce flow, but they do not expand assessment capacity. Code-generation throughput and assurance throughput should scale together.

What happens when assurance falls behind

The failure modes are not unique to AI-generated code. Higher change volume makes existing weaknesses in delivery processes more visible. Tests may pass while testing the wrong requirement. Tests generated from the same assumptions as the implementation may repeat the same blind spots. Security checks may miss business-logic, authorization, or workflow flaws.

• A new dependency is accepted without enough review.
• Architecture changes occur across several small changes without anyone assessing the combined effect.
• Reviewers approve changes they have not had time to understand.
• High-volume alerts lead to routine dismissal.
• Generated changes alter tests, build rules, security policies, or approval workflows that are supposed to assess those same changes.
• Changes compile and deploy while traceability remains incomplete.
• A problem appears later through incorrect business behavior, a security incident, operational instability, or difficult maintenance.

How should teams control what the coding agent can do?

Agent authority should be controlled before code reaches review. Run coding agents in isolated workspaces where practical. Give each session only the repository, branch, files, commands, and systems required for the task. Avoid production credentials and unrestricted access to deployment environments. Use short-lived credentials where supported, restrict direct changes to protected branches, limit access to secrets, and control which external package sources and code repositories the agent can use.

Coding agents may read issue descriptions, documentation, source files, comments, web pages, dependency documentation, and other content. Some of that content should be treated as untrusted because it may contain instructions that attempt to redirect the agent. This connects to excessive agency and tool-use risk and to prompt injection and instruction manipulation.

• Set clear task boundaries and stop conditions.
• Detect changes outside the requested scope.
• Record the initiating user and the authority granted to the agent.
• Require stronger approval before an agent modifies identity controls, authentication, authorization, security settings, build and deployment workflows, test requirements, code-scanning configuration, secrets handling, infrastructure, production configuration, database migrations, agent permissions, or its own review policies.

How should teams control what can be merged?

Use an executable definition of done. Convert written standards into repeatable checks where possible. A change should be unable to merge until the checks required for its language, system, environment, and risk level have completed successfully. GitHub required status checks and code-scanning merge protection are examples, not universal requirements.

• Successful build, unit tests, integration tests, contract tests, regression tests, and negative tests.
• Static code analysis, dependency vulnerability review, new dependency approval, secret detection, infrastructure configuration checks, database migration checks, license checks where relevant, and policy checks.
• Confirmation that the change stayed within its stated scope.
• Exception records that include an owner, reason, scope, expiry, and follow-up action.

Agent-generated tests can be valuable, but some tests should be derived from requirements, acceptance criteria, previous incidents, threat models, and independent test cases. Tests should cover failure behavior and unauthorized behavior, as well as expected behavior. Changes should be small enough for reviewers and automated systems to understand. Large agent-produced changes should be split where practical. Changes to tests, security rules, build configuration, or review policy deserve stronger scrutiny because they can weaken later checks.

How should teams control what can be released?

Approving source changes is different from trusting a released artifact. Build release artifacts in a controlled build environment rather than relying on an artifact produced inside the agent's workspace. Link the released artifact to the reviewed source commit. A software bill of materials, or SBOM, identifies components and dependencies. It does not prove that each component is safe. Provenance is evidence showing where, when, and how an artifact was built. Build provenance establishes origin and build history, but it does not prove the code is correct or secure.

For important releases, sign or attest artifacts, verify evidence before deployment, restrict production deployers, keep development, test, staging, and production permissions separate, and confirm that the deployed artifact passed the required checks. AI-agent attribution and build provenance are separate evidence needs. SLSA and GitHub artifact attestations are examples, not required product choices.

AI systems also need review across models, data, dependencies, registries, and deployment workflows. AI coding agents can increase the rate at which software supply-chain changes enter those processes.

What should be verified after release?

Pre-release checks remain incomplete because production behavior depends on real users, data, integrations, and traffic. Monitoring is part of assurance, but it does not replace pre-release testing. Use production-like test environments, feature flags where appropriate, staged rollout, limited canary deployment, error monitoring, security monitoring, business-outcome monitoring, anomaly detection, deployment-to-change traceability, rapid rollback, and tested rollback procedures.

• Unexpected authorization failures or abnormal data access.
• Unusual outbound connections or dependency behavior that differs from testing.
• Increased error rates, repeated rollback, or policy bypass.
• Changed customer, financial, or operational outcomes.
• Incident-driven retesting that feeds production findings back into tests and policies.

Can one AI agent verify another AI agent's work?

A coding agent may generate tests, documentation, and review summaries. These outputs can accelerate assurance work, but they should not be the only basis for trusting the change. Tests generated from the same task and assumptions can reproduce the implementation's blind spots. Verification should include evidence derived from outside the generated implementation: deterministic tests, externally written acceptance criteria, known security rules, threat models, historical defects, independent test cases, static analysis, dependency intelligence, policy checks, human domain review, and production observations.

Another model may help challenge the implementation, find inconsistencies, or propose additional tests. A second model alone does not establish independence because models may share training patterns, context, tools, or assumptions. For high-impact changes, retain meaningful human review from someone able to assess the affected business and security behavior. Structured evaluation should test realistic misuse, permissions, workflow effects, and control failure before and after deployment.

Which changes still need human approval?

Approval should follow risk. Classification should be based on possible impact, data sensitivity, reversibility, reach, novelty, and change to security boundaries. File count or lines of code alone should not determine risk. A small change to authorization logic may require more scrutiny than a large documentation change.

Teams should automate low-risk decisions while reserving scarce human attention for higher-impact changes. The risk-classification process itself should be reviewed and monitored for systematic underclassification.

How can teams increase assurance capacity without adding queues?

Increasing assurance capacity means making good decisions faster without lowering the evidence threshold for high-impact changes. Slowing all code generation does not fix limited testing infrastructure, poor alert quality, unclear ownership, or weak release evidence.

• Run independent checks in parallel where dependencies allow.
• Use reusable secure implementation patterns, approved project templates, and approved dependency sources.
• Create temporary test environments automatically.
• Use risk-based review routes and predefine approval rules for common low-risk changes.
• Route findings to the team able to resolve them and reduce noisy or duplicate alerts.
• Automatically collect evidence from the delivery process.
• Present reviewers with the change, affected risk areas, test evidence, and unresolved findings in one place.
• Keep changes small, measure where changes spend time waiting, expand testing and review infrastructure where queues consistently grow, and use policy as code where rules can be expressed reliably.
• Keep exceptions visible and time-bound.

What evidence should the process produce?

The evidence record should connect the initiating task, source change, checks, approvals, build artifact, deployment, monitoring, and rollback. Prefer evidence generated automatically by the delivery process rather than manually assembled screenshots. This extends logging, monitoring, and evidence generation into the software delivery path.

• Initiating user, work item, coding agent and tool version where available, repository, branch, task boundaries, permissions granted, relevant context, commands or tools executed where appropriate, files changed, and change summary.
• Assigned risk tier, tests and security checks run, tool and rule versions where material, results and unresolved findings, reviewers and approvals, exceptions and expiry dates.
• Source commit, build workflow, artifact identifier or digest, dependency record or SBOM, provenance or attestation, deployment environment and time, production observations, rollback record, and incident record.

Do not retain hidden model reasoning or chain-of-thought. Do not require full prompt retention in every case. Raw prompts, repository content, logs, and agent traces may contain secrets, personal data, customer data, or proprietary information. Retain enough information to investigate while minimizing sensitive content. Restrict access and define retention.

How should teams measure assurance capacity?

Do not use generated lines of code as a success measure. Establish a baseline, compare risk tiers, and look for bottlenecks and quality signals. Universal numeric targets are less useful than trends that reveal where assurance is falling behind generation.

• Time from proposed change to completed assurance decision, wait time for tests and human review, and time by risk tier.
• Percentage of changes with complete required evidence, agent-generated changes rejected or revised by automated checks, and changes rejected or revised during human review.
• Exception and bypass rate, expired exceptions still in use, average and distribution of change size, test failure rate, flaky-test rate, security-alert noise, and false-positive rate.
• Rollback rate, escaped defect rate, escaped vulnerability rate, production incident rate linked to recent changes, percentage of high-risk changes with named approval, and attempts to modify files outside the requested scope.

Watch for growing queues, routine bypasses, falling review time for high-risk changes, larger unbounded changes, worsening alert noise, and increasing rollback or escaped-defect rates.

Practical implementation checklist

• Inventory where coding agents are in use.
• Record which repositories, commands, credentials, and environments each agent can access.
• Prevent direct changes to protected branches and remove production credentials from agent workspaces.
• Define three practical change-risk tiers.
• Protect tests, build rules, deployment rules, and security configuration from low-scrutiny modification.
• Convert the definition of done into required automated checks.
• Require tests derived from requirements and risk, not solely from generated implementation.
• Keep changes bounded and reviewable.
• Require named approval for high-impact changes.
• Build release artifacts in a controlled pipeline.
• Link releases to reviewed source, checks, approvals, and artifacts.
• Generate dependency and provenance evidence where appropriate.
• Use staged release and tested rollback.
• Monitor assurance queues, bypasses, failures, and production outcomes.
• Feed incidents and review findings back into tests and policy.

FAQ

Sources and deeper reading

NIST SSDF Version 1.1 is the final publication. NIST SP 800-218 Rev. 1, SSDF Version 1.2, is listed by NIST as an initial public draft. GitHub features are included as implementation examples. SLSA provenance describes artifact origin and build process; it does not prove code quality, security, or agent authorship. The OWASP B1-B4 coding-agent trust-boundary model is labeled as a community contribution.

• NIST Secure Software Development Framework Version 1.1, final
• NIST SP 800-218 Rev. 1, Secure Software Development Framework Version 1.2, initial public draft
• NIST NCCoE Secure Software Development, Security, and Operations Practices
• GitHub rulesets and required status checks
• GitHub code-scanning merge protection
• GitHub artifact attestations
• SLSA Build Track, version 1.2
• SLSA Build Provenance, version 1.2
• OWASP Prompt Injection
• OWASP B1-B4 Trust Boundary Model for AI Code Generation Agents, community contribution