When security teams use an AI Agent to continuously organize scan results, they quickly encounter a practical question: Once the AI Agent identifies a suspected vulnerability, can it verify the issue on its own? If it has already generated a patch, can it deploy the update directly to a production system? If management merely states that “humans are responsible for critical operations” without clearly specifying when the AI Agent must stop and wait for human approval, it will also be difficult to determine who authorized the action if something goes wrong.
The Cloud Security Alliance (CSA) recently proposed the Vulnerability Operations (VulnOps) model, which calls on enterprises to continuously integrate vulnerability information from the development stage, deployed systems, and external disclosures instead of relying solely on periodic scans and batch remediation. For enterprises preparing to introduce security-focused AI Agents, this approach raises an even more practical issue: They must clearly define the AI Agent’s operational permissions and human approval checkpoints while retaining complete, auditable records. Only then can they establish exactly how far the AI Agent is allowed to proceed.
Which Upstream Tasks Can Be Assigned to an AI Agent?
An AI Agent is well suited to handling tasks that do not alter systems, such as consolidating information from different scanning tools and vendor advisories, removing duplicate entries, comparing affected software versions, and identifying hosts or applications that may be affected. An AI Agent can also prioritize remediation based on predefined rules and recommend fixes. However, its output must specify which data sources were used and which asset information still requires confirmation. It must not present “potentially affected” as “confirmed vulnerable.”
Prioritization should not be based solely on Common Vulnerability Scoring System (CVSS) scores. CSA recommends that enterprises also consider whether a system is exposed to the public internet, how critical it is to business operations, the likelihood that a vulnerability will be exploited, and whether evidence of active exploitation already exists. Teams can also refer to CISA’s Known Exploited Vulnerabilities (KEV) Catalog and the Exploit Prediction Scoring System (EPSS). An AI Agent can prioritize the backlog using these factors, but security personnel must still confirm that the asset and operational information is accurate.
Enterprises can therefore begin by granting only four categories of permission: reading, organizing, comparing, and recommending. The AI Agent should be prohibited from establishing external connections, executing attack commands, or modifying production systems. Before launching a pilot, the team must also confirm which data the AI Agent can access, which tools it can invoke, and whether each conclusion can be traced back to its supporting data.
Which Vulnerability-Related Actions Always Require Human Approval?
When validating a vulnerability, an AI Agent may send actual exploit payloads to a system, create test accounts, or change a service’s state. Even when the sole purpose is to confirm the risk, these actions may alter data, disrupt services, or trigger system alerts. CSA therefore recommends requiring human approval before an AI Agent performs exploit validation and limiting execution to authorized environments. At a minimum, the approval request should clearly specify the target system, permitted testing methods, execution window, stop conditions, and responsible person. This prevents a simple “testing approved” statement from being interpreted as unrestricted authorization.
Remediation in production environments should be managed separately. An AI Agent can prepare remediation recommendations, test procedures, rollback plans, and draft change requests. However, actions that alter the production environment—such as installing updates, modifying configurations, adjusting access rules, or restarting services—should still require approval from a named individual. Cloud-native applications can use automated deployment to accelerate updates, but traditional enterprise systems and industrial control systems involve dependencies, downtime risks, and maintenance windows. The same automated update process cannot simply be applied across all of them.
An AI Agent should also not submit external vulnerability disclosures on its own, because disclosure content may involve remediation timelines, the scope of affected systems, and legal liability. Enterprises should establish three separate checkpoints at which the AI Agent must stop and wait for human approval: validation testing, production deployment, and external disclosure. They should also assign responsibility to security personnel, system owners, and external communications contacts. If the AI Agent exceeds the approved targets, tools, or execution window, the workflow must stop immediately; the original approval cannot continue to be used.
How Can Approval Rules Be Embedded in the Workflow Instead of Remaining Only in Meeting Notes?
Enterprises can begin by dividing the vulnerability management process into six stages: information gathering, impact confirmation, validation testing, remediation recommendations, production deployment, and external disclosure. Each task should then be classified as “eligible for automated execution,” “requiring approval before execution,” or “prohibited from being assigned to an AI Agent.” For each stage, enterprises should also clearly define the input data, permitted tools, accessible data scope, approving role, and procedures for handling exceptions. This allows development, security, and IT operations teams to make decisions using the same set of rules.
Enterprises can configure human approval before workflow handoffs in EgentWrX. After the AI Agent completes the upstream work, the process pauses and resumes only after a person approves it. Enterprises can also use organizational structure and job responsibilities to define, at multiple levels, who may use an AI Agent and which data each person may access. The platform records the actions performed by the AI Agent, enabling enterprises to verify the integrity of audit logs and export them. The system also records when an administrator downloads audit logs. Enterprises can use these mechanisms to configure approval checkpoints and review the entire process afterward. However, they must still define in advance who is responsible for approval and which criteria that person should use when making the decision.
For every vulnerability, enterprises should retain records of at least the AI Agent’s actions, the user, the approver, the approval time, the deployment outcome, and any exception handling. Performance should not be assessed solely by the number of vulnerabilities closed. Enterprises should also track the change failure rate, whether vulnerabilities recur, and which risks remain unresolved. If a vulnerability cannot be remediated immediately, the enterprise can restrict access or implement other compensating controls. However, it must still assign an owner and a resolution deadline while continuing to track remediation progress.
CSA’s proposed Absorption Rate is calculated by dividing the number of items resolved during the past 30 days by the number of new items recorded during the same period. A value below 1 means that new items are accumulating faster than they are being resolved; a value above 1 indicates that the backlog is gradually shrinking. Enterprises can begin with a pilot involving selected production systems and development processes. Each month, security and operations teams can jointly sample and review approval records, change failures, and recurring vulnerabilities before deciding which upstream tasks can be more broadly automated by an AI Agent.
FAQ
Can an AI Agent scan production systems on its own?
Yes, but only through scans that have already been approved and whose targets and execution windows are clearly defined. Enterprises must also restrict in advance the tools, network segments, and data scope available to the AI Agent. If a scan could affect service availability or includes exploit testing, separate human approval must be obtained. Authorization for a standard vulnerability scan cannot be reused.
After an AI Agent finds a high-risk vulnerability, can it install the update directly?
Allowing an AI Agent to update a production system directly is not recommended. The AI Agent can document the affected scope, remediation recommendations, test procedures, and rollback plan. Before the update is installed, however, the system owner should still review dependencies, downtime risks, and the maintenance window. Traditional enterprise systems and industrial control systems require particular caution.
How should a vulnerability that cannot be remediated immediately be handled?
Enterprises can restrict access or implement other compensating controls to reduce the risk of exploitation. However, they must still assign an owner, set a resolution deadline, and continuously track the unresolved risk and subsequent remediation progress. A temporary measure must not be treated as a permanent resolution.
Which records should be retained for human approvals?
At a minimum, enterprises should record the AI Agent’s actions, the user, the approver, the approval time, the approved scope, the deployment outcome, and any exception handling. They should also correlate this information with change failures, recurring vulnerabilities, and unresolved risks to determine exactly where a remediation process went wrong.
References
- AI Accelerates Vulnerability Discovery as CSA Proposes the VulnOps Model to Improve Enterprise Vulnerability Management — iThome summarizes CSA’s proposed VulnOps model, metrics, and implementation recommendations.
