AI Vulnerability Management: Deploy Agents Safely

Introduce AI vulnerability management as an evidence-producing step in your security workflow, not as permission for a scanner to control production. Start with a bounded repository and isolated test environment. Let the agent investigate and propose a fix; have a qualified person validate the finding, approve the exact change and send it through the release process you already trust.

The business case is less time spent interpreting findings and preparing repairs. That benefit must be measured against reviewer effort, missed defects and the new access the agent receives. An impressive demonstration is not evidence that a tool can safely handle your source code, customer data or deployment credentials.

This is an ITECS-recommended pilot plan, researched September 29, 2026 using NIST, OWASP and current GitHub guidance. It is not a vendor ranking, a compliance certification or a claim that any agent finds every vulnerability. Our AI DevOps services address the surrounding operating process: environment separation, testing, monitoring and rollback.

Define the job before choosing the agent

Separate three jobs: discovery identifies a possible weakness; validation establishes whether it is real and relevant; remediation changes the system. Permission to read a repository does not authorize running its code. Permission to generate a patch does not authorize merging or deploying it. Record which job the pilot can perform and which decisions remain with people.

Choose one recurring problem, such as reviewing authorization changes in an internal application. Avoid starting with every repository or an unrestricted network scanner. If the existing backlog lacks an owner, an asset inventory or a reliable patch process, resolve those gaps first. Faster discovery will not resolve an unmanaged queue.

NIST's Secure Software Development Framework, SP 800-218, describes security practices that fit into an existing software development lifecycle. The practical implication here is to add AI evidence to your established engineering controls, not create a parallel route around them.

Phase 1: agree on scope, data and stopping conditions

Write rules of engagement before the first scan. Name the business sponsor, security lead, repository owner and release owner. Identify permitted repositories, exact code revisions, test systems, allowed techniques, prohibited targets, operating window and resource limits. Explicitly exclude production exploitation, customer tenants and third-party systems unless separately authorized by their owners. Access is not permission to test.

Specify who can stop the run and how: cancel jobs, revoke the identity and disable the integration. Stop on unexpected sensitive data, an out-of-scope target, unexplained outbound traffic, runaway retries or service degradation. Agree where evidence goes and who receives an incident report. NIST SP 800-115 provides the broader foundation for planning security tests, analyzing findings and choosing mitigations; it is not AI-specific guidance.

Before sending proprietary code to a provider, have the data and procurement owners verify the exact product, account tier and contract. Ask what source, prompts, outputs, telemetry and files are retained; for how long; who can access them; whether training use is permitted; where processing occurs; which subprocessors receive data; and how deletion, incident notification and termination work. Save the dated answers and applicable settings. A no-training statement alone does not establish zero retention.

If those terms do not fit the repository's classification or client commitments, keep the pilot synthetic or choose an approved processing arrangement. NIST's Generative AI Profile addresses third-party, data and lifecycle risks. The decision is about the actual data path, not whether a product is marketed as private. A local sandbox can still send context to a hosted model.

Phase 2: prove the boundaries with synthetic cases

Build a small ground-truth set of intentionally vulnerable and safe examples that resemble your language, frameworks and access rules. Use invented users and records, not a convenient copy of production. Include patched historical patterns only when the copied material is approved. Keep some cases hidden from prompt tuning so the evaluation tests more than memorization.

Run the pilot in a disposable, isolated sandbox with no production credentials, host administration socket or route to production services. Limit filesystem mounts and outbound destinations to what the task needs. Review setup scripts before execution. A container label alone does not prove isolation; verify the effective permissions, mounts and network paths. Destroy test state under the agreed retention policy after preserving necessary restricted evidence.

Treat code and its surrounding text as untrusted input. A comment, README, issue, error message or tool response can try to redirect an agent. OWASP's Secure Coding with AI guidance describes these indirect-instruction risks. Retrieved content may explain the application, but it cannot grant authority to upload files, disable checks or install a new tool. Review persistent agent instructions and dependency changes as security-sensitive source changes.

Give the agent a dedicated, short-lived identity limited to the approved repository and task. Separate read access from patch-branch write access; do not lend it a developer's broad personal credentials. Keep secrets outside prompts and reports, verify expiry and revocation, and enforce permissions in the runner, identity system and tool interfaces. OWASP's AI Agent Security guidance supports scoped tools and explicit approval for consequential actions. A prompt asking the agent to be careful is not an access control.

Red-team the workflow inside the sandbox. Use harmless fixtures that ask for an out-of-scope file, attempt an unapproved destination, claim approval that was never given, or try to weaken a test. Test expired credentials, missing logs and an interrupted job as well. The expected outcome is a blocked action with an understandable record, not merely a polite refusal in the final answer. Rerun these cases when the model, agent, tools or permissions change.

Phase 3: add pre-submit scans without granting merge rights

After the sandbox trial, run the agent in read-only shadow mode on approved code changes. Compare its reports with the current reviewers and scanners before making its output a release dependency. For pre-submit scanning, define whether the trigger is a developer action or a pull-request update; bind results to the exact commit and rescan after changes. A stale green result must not approve a different revision.

Keep untrusted pull-request code away from privileged runners and deployment secrets. If analysis or testing requires execution, route it to the isolated environment. Time out incomplete runs and report them as incomplete, not clean. Start with changed code plus justified context; document the coverage limit rather than implying that a diff scan audited the entire application.

Each finding should carry a source revision, affected location, proposed weakness, relevant preconditions, restricted evidence, likely business impact and a named reviewer. The reviewer classifies it as confirmed, false positive, duplicate or unresolved. Require enough evidence to reproduce the issue safely in the authorized test environment. An agent's confidence score is not a substitute for reproduction or expert analysis.

Reconcile disagreements instead of taking a vote between tools. Check whether the code is reachable, whether an existing control applies and whether the finding concerns the deployed version. Keep unresolved cases visible. Set priority using actual exposure, asset importance and applicable exploitation evidence, not the agent's severity label alone. Confirm a claimed CVE against its original advisory and affected versions.

Phase 4: review the fix, then verify the deployed result

Allow a patch proposal only after the finding is understood. Request a narrow diff, an explanation of the root cause, a regression test and evidence of preserved behavior. A qualified human approves the exact change before it is merged or applied to a shared environment. If the agent changes the patch after approval, review the new revision. Keep production credentials with the established release system, not the scanning agent.

GitHub's security and quality AI application card warns that Autofix suggestions can be partial, fail to correct a weakness or introduce another vulnerability. Its guidance calls for reviewing suggestions and verifying dependency changes. Those limitations are a useful reminder: generating a plausible repair and demonstrating a safe repair are different tasks.

Run your existing static analysis, dependency and secret scans, build checks and relevant application tests on the candidate. Use dynamic testing only against authorized environments. Inspect changes to security rules and tests so a disappearing alert is not simply a suppressed rule or deleted assertion. Where no scanner covers the underlying logic, retain manual verification and a targeted regression test rather than claiming independent tooling proved the fix.

Before release, record the accepted commit, immutable artifact, approver, previous release and recovery procedure. After deployment, verify that the intended artifact is running and repeat the relevant security and business checks. A merged pull request is not a remediated production system. Our agent evaluation guide expands the distinction between a good-looking answer and verified completed work.

Example: an invoice-export authorization finding

Consider a hypothetical internal application with invented test accounts. The agent reports that an invoice export may return another customer's records. A reviewer recreates the behavior with two synthetic tenants in the sandbox and confirms the authorization gap. No production records or live customer endpoints are used.

The proposed repair adds the missing tenant check. The team tests both cross-tenant denial and legitimate same-tenant export, then reviews the complete diff for unrelated changes. Existing scans and regression tests run before a human approves the candidate. The release owner deploys it through the normal pipeline and checks the resulting version. If the initial report had misunderstood an existing authorization layer, the team would record a false positive rather than merge a needless change.

Keep an audit trail and a usable stop-and-recover path

Link each run to its source snapshot, agent and model version, tool versions, effective identity, permitted scope, timestamps, tool actions, findings, reviewer decisions, patch and release. Record whether required checks actually ran. Restrict access and redact secrets; logs must not become another ungoverned copy of client code. Preserve the evidence needed for investigation under the organization's retention requirements.

Assign separate recovery owners for the agent and the application. Stopping a misbehaving scan may require revoking access and quarantining its workspace; a faulty release may require the prior artifact or a reviewed forward fix. Rolling back a security patch can reopen the original weakness, and rolling back application code cannot necessarily reverse a database change. Decide compensating controls and data-recovery needs before approving such a release.

Measure verified security work, not agent activity

Use comparable tasks and severity groups to establish a baseline, then report the sample size and observation window. Agree acceptable thresholds before reviewing pilot results. The following scorecard is an ITECS measurement recommendation, not a vendor benchmark or promised improvement.

For illustration only, 18 confirmed issues among 24 adjudicated unique findings means 75% precision. It says nothing about vulnerabilities the agent never reported. Report unresolved cases separately, and test known-case detection so a quieter agent does not appear better simply by flagging less. Repeat runs to expose variability; include the cost of rejected suggestions and repairs that needed rework.

Expand one repository or action type at a time only when the security and engineering owners accept the evidence. Pause expansion after a boundary violation, unexplained data transfer, unacceptable missed-case rate or rising escaped defects. A useful pilot can end with a narrower role: an agent that prepares strong finding summaries may be worth keeping even when patch generation is not ready.

The goal is a faster path from a real weakness to a verified, maintainable repair, with accountable people at the decisions that matter. If your team is building that path, define the first bounded workflow with ITECS before connecting an autonomous scanner to business-critical systems.