How the Risk Registry works
Every entry is built from evidence Moona Intelligence already holds. This page states the definitions, the publication gates and the complete AESS 0.1 severity specification, so a reader can check any entry against the rules that produced it.
The model
The registry connects three layers that already exist on this site. Moona Intelligence records document what happened and cite their sources. The Risk Registry classifies what those records establish. The protocol evidence dataset records what the market is building against it. Nothing in the registry introduces a claim the published corpus does not carry.
An Agent Execution Weakness (AEW) is a recurring class of execution authority failure: a pattern that can recur beyond one implementation, whose execution or authority distinction is technically meaningful, and whose missing control can be articulated. It is analogous in function to a weakness taxonomy such as CWE, without claiming that lineage or authority.
An Agent Execution Vulnerability (AEV) is a concrete vulnerability or exposure in an identifiable product, integration, configuration or execution mechanism. Every AEV is an instance of at least one AEW, records the execution authority facts of what happened, and carries per claim provenance to the Intelligence records and sources supporting it.
Evidence rules
- Every material factual claim links to a published Intelligence record or a source those records cite. The build fails if a reference points at anything else.
- Claims are labelled by basis: verified fact, vendor claim, independent reporting, inference or hypothesis. The registry never rounds one up into another.
- When the evidence does not establish a field, the field says unknown. Unknown is displayed, not hidden, and it is never treated as either safe or critical.
- Where primary source access was blocked during verification, the limitation is recorded on the entry rather than silently worked around.
Publication gates
Entries start as candidates. A weakness is published only when the pattern cannot be represented by an existing AEW, can recur beyond one implementation, is supported by evidence, and its missing control can be stated. A vulnerability is published only when the affected mechanism is identifiable, the consequential action is documented, the evidence is authoritative or independently credible, the entry is not a duplicate, the evidence state is explicit, at least one published AEW is associated, and severity comes from the versioned calculator below. An entry that fails any of these stays a candidate and is never counted as a published vulnerability.
Lifecycle transitions are validated in code: an entry moves between candidate, published, disputed, resolved, deprecated and withdrawn states only along allowed paths, and every transition carries a date, a rationale and supporting records.
AESS 0.1: Agent Execution Severity Score
AESS is an open Moona specification in its initial version. It is not CVSS, it is not endorsed by the CVE program, and it is not an industry standard. It exists so that severity is a transparent, versioned, deterministic function of stored inputs: identical inputs always produce the identical score, and no editor ever types a final number.
Ten dimensions are assessed, each with a closed set of allowed values. Four measure impact and six measure the failure of control around the action. Each dimension carries a fixed share of its group, published in the tables below.
The formula
Each group score is the mean of its known dimensions, using the published shares, with the shares of unknown dimensions redistributed proportionally across the known ones. The final score is
score = 10 x (55% x impact + 45% x control failure)
rounded to one decimal. The severity bands over the rounded score are low (0.0 to 3.9), medium (4.0 to 6.9), high (7.0 to 8.9), critical (9.0 to 10.0).
Unknown handling
An unknown dimension is excluded from the calculation and shown as X in the vector, so a reader can see exactly what the score does not rest on. Unknown neither raises nor lowers the score. Below a minimum evidence threshold no score is published at all: consequence must be established, at least one of authority mismatch, human control or binding integrity must be established, and at least 5 of the ten dimensions must be known. Below that the entry is visibly unscored rather than carrying a number built mostly on unknowns.
Dimensions and allowed values
Impact dimensions
C Consequence40% of impact
What did the attempted or completed action do, or demonstrably stand to do?
| Value | Code | Weight | What the evidence must show |
|---|---|---|---|
| none | N | 0 | No consequential effect executed and none was demonstrably in reach. |
| degraded | D | 0.35 | Limited harm: degraded service, limited exposure, or a consequential action reached but stopped short of execution. |
| material | M | 0.7 | Real loss executed or demonstrably reachable: data destroyed or altered, money moved, production changed, obligations created. |
| severe | S | 1 | Loss at the scale of the business or of many parties: wholesale destruction, safety impact, or systemic exposure. |
| unknown | X | excluded | The evidence does not establish this dimension. |
R Reach25% of impact
How far did or could the effect extend?
| Value | Code | Weight | What the evidence must show |
|---|---|---|---|
| single | S | 0.25 | One resource, workspace or user. |
| organisational | O | 0.6 | Multiple resources or a whole system inside one organisation. |
| systemic | Y | 1 | Crosses organisations, tenants or customers. |
| unknown | X | excluded | The evidence does not establish this dimension. |
RV Reversibility20% of impact
Once executed, can the effect be undone?
| Value | Code | Weight | What the evidence must show |
|---|---|---|---|
| reversible | R | 0 | Cleanly undoable through an ordinary mechanism. |
| recoverable | P | 0.5 | Recoverable with effort, backups or third party cooperation. |
| irreversible | I | 1 | Cannot be undone, or recovery was shown to be unreliable. |
| unknown | X | excluded | The evidence does not establish this dimension. |
PG Propagation15% of impact
Does the effect spread beyond the first action?
| Value | Code | Weight | What the evidence must show |
|---|---|---|---|
| none | N | 0 | The effect stays where the action landed. |
| potential | P | 0.5 | A concrete propagation path exists in the evidence but was not observed operating. |
| observed | O | 1 | The effect was observed spreading to further systems, actors or actions. |
| unknown | X | excluded | The evidence does not establish this dimension. |
Control failure dimensions
AM Authority mismatch25% of control failure
How far did the authority presented fall short of the authority the action required?
| Value | Code | Weight | What the evidence must show |
|---|---|---|---|
| none | N | 0 | The acting system held applicable authority for the executed action. |
| partial | P | 0.5 | Authority existed for the task but did not extend to the specific action executed. |
| full | F | 1 | No applicable authority existed for the executed action. |
| unknown | X | excluded | The evidence does not establish this dimension. |
HC Human control20% of control failure
What human control stood before execution?
| Value | Code | Weight | What the evidence must show |
|---|---|---|---|
| independent-blocking | I | 0 | A blocking approval by a party independent of the requester stood and held. |
| blocking | B | 0.35 | A blocking approval existed but was not independent of the requester. |
| advisory | A | 0.7 | Humans could observe or advise but could not block execution. |
| none | X | 1 | No human control stood before execution. |
| unknown | X | excluded | The evidence does not establish this dimension. |
BI Binding integrity20% of control failure
Did the authorization bind to the action actually executed?
| Value | Code | Weight | What the evidence must show |
|---|---|---|---|
| intact | I | 0 | What was approved is what executed. |
| partial | P | 0.5 | The approval attached to a broader object than the executed action, so the binding is real but loose. |
| broken | B | 1 | The executed action differed from what any authorization attached to. |
| unknown | X | excluded | The evidence does not establish this dimension. |
AU Autonomy15% of control failure
How autonomously was the agent operating at the moment of execution?
| Value | Code | Weight | What the evidence must show |
|---|---|---|---|
| supervised | S | 0.25 | A human initiated or confirmed each step. |
| semi-autonomous | M | 0.6 | The agent ran multi step work with intermittent human involvement. |
| autonomous | A | 1 | The agent selected and executed actions without per action human involvement. |
| unknown | X | excluded | The evidence does not establish this dimension. |
P Privilege10% of control failure
What privileges were available to the agent at execution?
| Value | Code | Weight | What the evidence must show |
|---|---|---|---|
| minimal | L | 0.25 | Narrow, task scoped privileges. |
| elevated | E | 0.6 | Privileges beyond the task, short of administrative reach. |
| broad | B | 1 | Administrative, destructive or production wide privileges. |
| unknown | X | excluded | The evidence does not establish this dimension. |
DT Detectability10% of control failure
How visible was the action to the humans responsible for the system?
| Value | Code | Weight | What the evidence must show |
|---|---|---|---|
| immediate | I | 0 | Surfaced to responsible humans as it happened. |
| delayed | D | 0.5 | Discovered after the fact through ordinary review or reporting. |
| silent | S | 1 | Left no record surfacing it, or actively misrepresented what happened, so discovery depended on chance or external effects. |
| unknown | X | excluded | The evidence does not establish this dimension. |
The vector
Every assessment publishes its vector, for example AESS:0.1/C:M/R:O/RV:I/PG:N/AM:F/HC:X/BI:B/AU:A/P:B/DT:D, listing each dimension code and the code of its value, with X for unknown. The dimension values are shown beside every score so a reader can challenge the assessment, and the calculator that turns a vector into a score ships in this repository with unit tests for boundaries, missing values, determinism and severity bands.
What this is not
The registry does not convert every Intelligence record into a risk entry, does not publish an AEV because an article discusses a general risk, and does not create protocol candidates from single vendor announcements. Records that produce no registry change are listed with the reason, and totals shown anywhere are computed from the actual published data. A machine readable copy of the registry is at /risk-registry.json.