[AAI suit] Add a per-action-class decision-rights / reversibility mapping dimension to companion-mappings-1.0.yaml

[Mayur021]

Is your feature request related to a problem? Please describe.

The Agentic AI (AAI) suit's mitigations already reason about action-class authority and reversibility, but only in card explanation prose, not as
a structured mapping dimension like STRIDE / CIA / MITRE ATLAS / OWASP LLM / OWASP Agentic / AITG / AISVS.

Two examples from the current cards:

• AAI9 (CoPirate, unauthorized system modification) names the root cause as "The system does not distinguish between read operations and
  destructive or privileged write operations when the request originates from an AI agent" and prescribes "Require explicit human approval for any
  agent action that modifies security-relevant configuration, permissions, or infrastructure state."
• AAIK (GPI-3.1415, catastrophic cross-system impact) prescribes "least privilege applied at the action level, not just at the credential level,"
  "Never allow a single agent decision to trigger bulk irreversible changes across systems," and "Wrap all destructive or state-modifying agent
  actions in reversible transactions or dry-run modes."

That is per-action-class authority and reversibility reasoning, stated as prose. Because it is not a structured field, it can't be queried,
filtered, or kept consistent across the suit the way the other dimensions are. A facilitator currently can't answer "which AAI cards involve
irreversible high-impact actions that need a human authorization gate?" from the mappings file.

Describe the solution you'd like

Add a decision_class dimension (with a decision_class_print variant, consistent with the existing schema) to each AAI card in
source/companion-mappings-1.0.yaml. The taxonomy is a four-level ladder graded by reversibility and required authority:

ID	Label	Authority gate
RO	Read-only	Autonomous
BR	Bounded-reversible	Autonomous, logged
BI	Bounded-irreversible	Human authorization
IH	Irreversible high-impact	Human authorization + evidence threshold

Example rows (shape only; the full per-card mapping would follow in the PR, in the style of #2833):

  # AAI9 — unauthorized configuration / permission / IAM modification
  decision_class: [ BI, IH ]
  decision_class_print: [ "Bounded-irreversible (human authorization)", "Irreversible high-impact (human authorization + evidence threshold)" ]

  # AAIK — catastrophic cross-system impact via excessive agency
  decision_class: [ IH ]
  decision_class_print: [ "Irreversible high-impact (human authorization + evidence threshold)" ]

  # AAI4 — unbounded consumption / cost harvesting
  decision_class: [ BR ]
  decision_class_print: [ "Bounded-reversible (autonomous, logged)" ]

This makes the authority/reversibility reasoning already present in the card prose queryable and consistent, and gives facilitators a fast way to
surface the cards whose mitigations require a human-in-the-loop gate.

Describe alternatives you've considered

• Leaving the reasoning in prose only — rejected because it can't be queried or kept consistent, and the prose already varies in how explicitly
  each card states the action class.
• A free-text reversibility note per card — rejected because an enumerated class is filterable and avoids drift.
• A separate standalone document — rejected because the mapping belongs next to the other dimensions in the same file, where facilitators already look.

Additional context

• Scope is the AAI suit only, since that is where the prose already leans hardest on action-class reasoning. Extending the dimension to the LLM /
  CLD / DVO suits where applicable would be follow-up work, not part of this change, to avoid re-opening the recently merged LLM/CLD mappings.
• The four-class taxonomy aligns with emerging governance work that grades autonomous-action authority by reversibility and blast radius — e.g.
  OWASP SPVS 1.5-AI, where I have an open PR adding a related runtime decision-rights control ([ADDED] V1.3.7 — NHI runtime decision-rights matrix www-project-spvs#15) — and is consistent with the AISVS least-privilege / continuous-authorization direction the suit already maps to.
• @suvroc since you lead the AAI suit, I'd value your input on the class boundaries and would be glad to co-author. @sydseter @cw-owasp tagging per CODEOWNERS for visibility.
• Per CONTRIBUTING.md, raising this as an issue first and requesting assignment before opening a PR. Happy to author the full per-card mapping PR in the Add security mappings (STRIDE, CIA, MITRE ATLAS, OWASP LLM Top 10, CWE) for all LLM companion cards (LLM2-LLMK) #2833 format (per-card reasoning table + authoritative-source references) once scoped.

[sydseter]

@Mayur021 to me, this seems like a good idea. @suvroc what do you think? Does the labeling and authority gate make sense to you, or should they be slightly differently described?

I see there are some who prefer to merge the Bounded-irreversible and Irreversible high-impact together and instead use "External-reversible", for the 3. category instead.

What makes more sense here?

E.g:

ID	Label	Authority gate
RO	Read-only	Autonomous
BR	Reversible	Autonomous, logged
ER	External-reversible	Human authorization
I	Irreversible	Human authorization + evidence threshold

[Mayur021]

@sydseter thanks, glad it resonates. Honestly I think your relabeling is cleaner than my original, and here is why.

My RO/BR/BI/IH mixed two axes: reversibility (RO/BR vs BI/IH) and impact magnitude (BI vs IH). That impurity is exactly what your version fixes.
Read-only / Reversible / External-reversible / Irreversible is a single coherent axis, the mechanism of reversal, and it maps to authority more cleanly:

• Read-only: nothing to undo, so autonomous
• Reversible: the system can undo it directly, so autonomous and logged
• External-reversible: recoverable only via an external process (restore from backup, vendor action, manual rollback), so human authorization
• Irreversible: cannot be undone, so human authorization + evidence threshold

One thing worth keeping from the "high-impact" idea: blast radius is a second, orthogonal dimension. The evidence threshold sits at Irreversible because you cannot undo a mistake, so you want higher confidence before acting. But blast radius can escalate any tier. A technically Reversible action applied across thousands of resources may warrant a gate that single-instance reversibility would not. So I would keep reversibility-mechanism as the primary axis (your four labels), with blast radius as a modulator that can raise the gate within a tier, rather than a fifth category.

Net: happy to adopt your RO / BR / ER / I labels. @suvroc since it is your suit, keen on your read: does External-reversible map cleanly onto the AAI scenarios (AAI9 config/permission changes, AAIK cross-system impact), or do those need the impact dimension surfaced more explicitly?

[sydseter]

The question is, can cards have multiple labels, and how should we deal with that? I am thinking that we should describe how multiple labels might apply to the same card in the explanation.md We should probably have a separate header for this.

[Mayur021]

@sydseter yes, and the array handles it the same way the other dimensions already do. stride, mitre_atlas, and owasp_aisvs are all multi-value, so decision_class: [ RO, ER ] is consistent with the existing schema rather than a new pattern.

On when multiple labels apply: a single card's scenario often spans actions of different reversibility. AAIK is the clearest case, the scenario covers identifying items (reversible) and bulk irreversible deletion in the same flow. So the card should carry every class its scenario can reach, not just the dominant one.

Agree on the explanation.md header. Since each card already has a Threat Modeling section (STRIDE, What can go wrong, What are we going to do about it), a Decision class section sits naturally right after it, mapping each label to the specific action it applies to rather than a bare list. For AAIK that would read as Reversible for the identify/enumerate step, and Irreversible for the bulk-delete step.

One rule worth stating in that section: when a card carries multiple classes, the authority gate defaults to the least-reversible class present.
If a scenario can reach Irreversible, the card gates at human-authorization-plus-evidence even though it also contains reversible actions.
Worst-case governs, so the reversible actions can't average the gate down. That keeps the label honest about the real blast radius of the card.

[cw-owasp]

Adding additional mappings is always useful, and the Companion Edition suits incorporate new ones. It's great to have this input.

I have no experience to share about this particular topic and proposed mapping, but I do think mappings should point to published and accepted standards/models/etc. That may not be the case yet for this?

Also, as a non-expert, the following looks like at least three different kinds of mappings (human vs autonomous, unauthorised vs authorized, and the other aspects) and wonder whether it is really a full taxonomy:

• Autonomous
• Autonomous, logged
• Human authorization
• Human authorization + evidence threshold

For example, questions like these spring to mind:

• What is the difference between a comma "," and a plus symbol "+"?
• Should "Human authorization" be "Human, authorized" for consistency with "Autonomous, logged"?
• Could "logging" also occur in the human categories?
• Could other permutations like "Autonomous, authorization" or "Human" occur?

I have no idea of the answers but worry we tag the cards one way, which then isn't an industry-accepted way. I am not questioning what the taxonomy should be, but whether it is mature enough to map to (yet). Forgive my ignorance if I haven't understood this.

[Mayur021]

@cw-owasp fair challenge, and worth taking seriously on both points. Thanks for it.

On the taxonomy. I think a column mix-up is doing most of the damage. The labels you quoted (Autonomous / Autonomous, logged / Human authorization / Human authorization + evidence threshold) are the authority-gate column from @sydseter's table, which is the recommended consequence, not what cards get tagged with. The taxonomy itself is the left column: Read-only / Reversible / External-reversible / Irreversible, a single axis, the mechanism of reversal. A card carries decision_class: [RO, ER], never the gate prose.

And you are right that the gate column, read as a taxonomy, mixes axes: actor (autonomous vs human) and safeguards (logging, evidence threshold), both orthogonal to reversibility. That is exactly why your questions have clean answers:

• comma vs plus: no semantic difference, just inconsistent drafting, should be normalized.
• logging in the human categories: yes. Logging is universal and belongs at every tier, so it should not sit inside the gate label at all.
• permutations like "Autonomous, authorization": yes, they can exist, which confirms actor and safeguards are separate axes from reversibility.

So the concrete fix for the messy-tagging risk you flagged: tag cards only on the RO/BR/ER/I axis, and move the authority-gate into explanation.md as non-normative guidance, not a card tag.

On maturity and mapping to accepted standards, you are raising the right bar and I will not overclaim. Per-action reversibility tiering is not itself a single ratified standard yet. But it is not novel either. It operationalizes principles that are accepted and published:

• Least privilege: NIST SP 800-53 AC-6.
• Human oversight for high-consequence actions: EU AI Act Article 14, and NIST AI RMF's risk-matched oversight under Govern/Manage.

Read that way, RO/BR/ER/I is just least privilege graded by reversibility, with human oversight escalating as reversibility drops. Those anchors are accepted. For completeness, NCSC and Five Eyes agentic-AI guidance use the same bounded-autonomy-with-escalation pattern, and I have a pending OWASP SPVS control proposing this axis (pending, not accepted).

So my suggestion is to anchor the mapping's provenance to least-privilege plus human-oversight (the accepted standards above) rather than present RO/BR/ER/I as a standalone novelty. That satisfies the Cornucopia discipline of mapping to accepted ground while still delivering the per-action dimension. The final maturity and timing call is yours and @suvroc's, and I am happy to gate inclusion behind whatever bar you both set.

I would rather ship something honest and narrow than tag cards in a way that ages badly.

[sydseter]

This is an interesting snag, yes, we should be careful. Several organizations are working on establishing a framework for AI Agent Authentication & Authorization.

E.g:
IETF: https://www.ietf.org/archive/id/draft-klrc-aiagent-auth-00.html
NIST: https://www.executivegov.com/articles/nist-nccoe-concept-paper-ai-agent-access-controls

So I believe what Colin says is correct. An issue we have is that we can’t easily remove or change a mapping once we have added it so we should be careful with doing it.
One way around is to do a more thorough investigation and apply the necessary changes to OWASP AISVS. Once merged, we can point to the AISVS requirements or guidelines here. I am not so fond of OWASP SPVS as it is still very immature and focused on software delivery pipelines. Here we want a more broader view.

[sydseter]

I believe this point regarding reversibility is mentioned to be a point that need more research in AISVS as well. That said, it might be very close, so it might be possible to already make the necessary changes to OWASP AISVS.

[Mayur021]

Agreed on all of it, and the AISVS route is the right call.

On the constraint: yes. Since a Cornucopia mapping is hard to pull once added, better not to anchor cards to a taxonomy that is still moving. Hold the decision_class mapping until there is something stable to point at.

On the home for it: AISVS is the broader fit and I will not argue for SPVS here. SPVS is scoped to the delivery pipeline, and per-action reversibility is a cross-cutting runtime concern, so it belongs in a standard that takes the broader view. The natural anchors look like C09 (Orchestration and Agentic Action) and C14 (Human Oversight), both of which already touch high-impact and irreversible actions and human-in-the-loop gating. As you note, reversibility is already flagged there as needing more work, so this is extending an existing line rather than adding a new concept, which is probably why it feels close.

Worth separating it from the IETF and NIST efforts you linked. Those are agent authentication and authorization: who the agent is and what it is permitted to touch. Reversibility is a different axis. Given the agent is authorized, how much autonomy the action gets should depend on whether it can be undone. The two compose: authz decides permission, reversibility decides the gate. So this would sit alongside the authn/authz work, not duplicate it.

Happy to do the thorough investigation and draft it. I would map the read-only / reversible / external-reversible / irreversible axis to a C09 (and/or C14) control, with the authority gate as guidance rather than normative prose, cross-referencing the IETF and NIST authz work plus least privilege (NIST 800-53 AC-6) and EU AI Act Article 14 human oversight as the accepted anchors. Which chapter would you and the AISVS leads prefer, and is there an open research issue I should attach to rather than open a fresh one?

Once it merges in AISVS, Cornucopia can point here cleanly.

[sydseter]

@Mayur021 I don’t have more then one commit on AISVS so I would add this suggestion there. It’s seems to be worthwhile so if you can, go ahead. We’ll align here once the pull-request there is merged.

[Mayur021]

@sydseter Thanks, will do. Opened the AISVS issue first per their contributing guide: OWASP/AISVS#820 ("C9.2: make reversibility a structured classification axis, separate from blast radius"). It targets C09 (Orchestration and Agentic Action) with a cross-reference to C14 (Human Oversight), mapping the read-only / reversible / external-reversible / irreversible axis to a control there, with the authority gate as guidance rather than normative prose. I've left the routing open for the AISVS leads (editorial clarification of the existing 9.2.x for v1.0, or new requirements in research/ for the next version), then I'll raise the PR and link it back here so the Cornucopia decision_class mapping can point to the merged requirement.

[suvroc]

I like the idea of adding a reversibility dimension. It categorizes the attack very well.
I think the impact depends on many other elements, so I would not define it on the card/

I disagree with the example mappings:

# AAI4 — unbounded consumption / cost harvesting
decision_class: [ ER (instead of BR) ]

Do we need Authority gates? Does it brings value to the players?

However I agree with @cw-owasp about referring to the established standard. This is a big problem.

human vs autonomous dimension doesn't match the cards, as for all of them according to the description it is unclear if the action was fully autonomous or not. There are no mention the trigger in purpose. For simplicity.
The same for authorized/unauthorized.

The taxonomy only refers to reversibility and that is ok.

@Mayur021
I don't understand your last claim about changing the dimensions.

[sydseter]

We could add reversibility as a common point in the explanation.md and keep it away from the mapping for now. It could be connected with authorization and autonomy where it makes sense, but I agree, it feels a bit immature and too unclear to be mapped.
I think the answer to how to approach mitigating against these issues using authorization gates is, it depends.

I fear that we might end up locking down discussions when we could open up for them. Keeping things vague is one of the game’s strengths as it allows the players freedom to freely associate according to their own context.

[Mayur021]

@suvroc @sydseter Agreed — keep reversibility as a shared lens in explanation.md, not a per-card mapping. A few clarifications:

• On my "changing the dimensions" line (sorry, that was unclear): I was agreeing with Colin — autonomy and authorized/unauthorized were only ever the authority-gate consequence, never a card dimension. The taxonomy is reversibility alone (RO/BR/ER/I). So we're aligned: no autonomy/authorization tags on cards.
• The AAI4 ER-vs-BR disagreement is exactly why per-card mapping is premature: reversibility depends on how the action is enacted, so a fixed class per card locks in a debatable call and removes the freedom that makes the game work — your point, @sydseter.
• On established standards (@cw-owasp's concern): that's the role of C9.2 — Make reversibility a structured classification axis (separate from blast radius) for approval routing AISVS#820 — mature the anchored version there (NIST 800-53 AC-6, EU AI Act Art. 14), and once it's a ratified control, explanation.md can reference it cleanly instead of carrying an immature taxonomy.

Net: reversibility as a discussion lens in explanation.md now, the normative version matures in AISVS, no card mappings. Works for me.