How AI Agents Can Apply a Team’s Risk Scoring Rules and Record Each Change

A vulnerability’s risk score decides what a security team fixes first.

Mature programs adjust it with rules of their own, such as moving anything on a known-exploited list to the front of the queue or ranking an internet-facing system above an internal one. Most apply those rules by hand, after the scanner has scored a finding.

Applied by hand, those rules are hard to repeat consistently and to explain afterward.

Orca Security says Custom Agents let a team apply the same rules inside its platform, with a record of each change on the alert. In its blog post on vulnerability scoring, Orca shows how a team can set one up and review what it does.

Teams Apply Their Own Rules After the Scanner Scores

The standard severity score, the Common Vulnerability Scoring System, rates how serious a vulnerability is in general. It does not know whether the affected software runs on an internet-facing system, holds sensitive data, or has an exploit in use right now.

A security platform can supply some of those missing facts from the environment itself. Orca’s risk scoring adds cloud context such as exposure, attack paths, and crown jewel status, which flags assets the business treats as critical.

Even with that context, many organizations hold rules specific to them, policy decisions only they can make. In an Orca example, a financial services team treats any vulnerability on the Known Exploited Vulnerabilities catalog from the Cybersecurity and Infrastructure Security Agency (CISA) as critical on a payment system, whatever its base score. In another, a healthcare provider raises the score of anything touching regulated data.

Applying such rules can mean exporting findings and re-scoring them in a spreadsheet. The scanner and the spreadsheet then give different answers, and no one can easily explain why a finding scored as it did, a question an auditor or engineering lead will eventually ask.

A Configured Agent Can Gather Evidence and Apply the Team’s Rules

Orca describes a Custom Agent as an AI agent a team configures in Orca with its own instructions, scope, trigger, and tools. Orca suggests a setup for vulnerability scoring that takes over the re-scoring teams otherwise do by hand: the agent gathers the facts behind each alert, then adjusts the score under the team’s rules.

In that setup, the team writes the rules as plain-language instructions, sets the scope to one alert at a time, and sets a trigger, for example every new vulnerability alert on a production account. The team also chooses the tools the agent can use: changing a score, adding a comment, searching the web, and opening a Jira ticket.

The instructions have the agent work in order on each open critical or high alert, gathering evidence first and applying the team’s rules second. It checks the vendor’s advisory to see whether the exact software is affected, looks for newly published exploits, and confirms the software is actually running.

Under those instructions, the score rises when the asset is a crown jewel or carries an administrator-level identity, when an attack path leads into production data, or when a new exploit has been published. It falls when the vendor says the software is unaffected, the asset is tagged development or sandbox, or the software is not loaded.

Reviewers Can Check Each Change Against the Rules

When an agent changes risk scores, a reviewer needs to see what it changed and why. The team’s instructions can set limits on what the agent may do, and every change is recorded.

Orca advises writing limits into the instructions, such as never lowering a score on web evidence alone, on an asset showing signs of attacker activity, or on one a human has already rescored. When a limit Blocks a change, the agent is told to leave the score as it is and report the score it recommends, along with the limit that stopped it.

In the Orca platform, every score change is recorded on the alert’s timeline, whether a person, an agent, or an integration made it. The timeline keeps the original score, the new score, the time of the change, and the agent’s name and type.

Orca suggests requiring a comment that names the rule and the evidence, for example that a vulnerability was raised to critical because it appears on CISA’s known-exploited list and sits on an internet-facing asset. An analyst, engineering owner, or auditor can read the alert’s history and decide whether to agree.

What This Means for SAPinsiders

Where a rule lives decides when it applies. A rule kept in a spreadsheet applies after the scanner has scored a finding, while a rule given to an agent watching new alerts applies as each one arrives. The timing decides whether the priority a team sees reflects its policy.

Automated decisions need written limits. An agent that can change a risk score acts with the organization’s authority, so the limits on that authority belong in writing. Written limits give security and GRC reviewers a policy they can read.

Explanation travels with the decision. When a change carries its author, timestamp, and reason, the explanation exists before anyone asks for it. In SAP security and GRC work, that gives an agent’s change the same footing as an analyst’s.