Repository navigation
[AAI suit] Add a per-action-class decision-rights / reversibility mapping dimension to companion-mappings-1.0.yaml #3018
Description
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.
Activity
sydseter commentedon May 20, 2026
@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:
Mayur021 commentedon May 20, 2026
@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:
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 commentedon May 20, 2026
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 commentedon May 20, 2026
@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 commentedon May 21, 2026
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:
For example, questions like these spring to mind:
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 commentedon May 21, 2026
@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:
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:
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 commentedon May 21, 2026
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 commentedon May 21, 2026
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 commentedon May 21, 2026
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 commentedon May 21, 2026
@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 commentedon May 22, 2026
@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 commentedon May 22, 2026
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:
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 commentedon May 22, 2026
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 commentedon May 23, 2026
@suvroc @sydseter Agreed — keep reversibility as a shared lens in explanation.md, not a per-card mapping. A few clarifications:
Net: reversibility as a discussion lens in explanation.md now, the normative version matures in AISVS, no card mappings. Works for me.
sydseter commentedon Jul 16, 2026
Issues has been merged in AISVS so we can go ahead and continue the work here.
7 remaining items
sydseter commentedon Jul 16, 2026
Also
cornucopia.owasp.org/cards/AAI9
Mayur021 commentedon Jul 16, 2026
Thanks, that is exactly what I needed. C9.2 is the right anchor, and 9.2.3's four classes (read-only, reversible, externally reversible, irreversible) are the taxonomy the lens should use, with 9.2.4 for enforce-by-class and 9.2.10 for the chain cases.
Mapping the cards you listed: AAI9 (config/permission change) is externally-reversible or irreversible, classify and gate (9.2.3/9.2.4). AAIX, AAIJ and AAIK all reach an irreversible step across a plan or an inter-agent hop, so they gate on the worst-case reversibility in the chain (9.2.10). AAIQ is the blast-radius case, where scale raises the gate within a class (9.2.4).
Two things before I draft. LLMK has no description in companion-cards-1.0-en.yaml on your branch, so I want to confirm the intended scenario before writing its note. And do you want a short reversibility note inside each card's explanation.md, or one shared block the cards point to? Either works, I will match whatever keeps it DRY.
sydseter commentedon Jul 16, 2026
You’ll find the LLMK description here
cornucopia/source/companion-cards-1.0-en.yaml
Line 68 in 4ae743c
Mayur021 commentedon Jul 16, 2026
Thanks, LLMK is the LLM-suit Excessive Agency card (Ava, missing human-in-the-loop), so it fits the same lens as the AAI cards.
Here is the reversibility lens plus a note for each of the six cards, all anchored to AISVS 1.0 C9.2 (9.2.3 classify, 9.2.4 enforce, 9.2.10 worst-case across a chain).
Reversibility lens (RO / BR / ER / I). Classify each action by how it can be undone, then gate on that class. Read-only observes and needs no gate. Reversible the system can undo directly. External-reversible is recoverable only through an outside process such as a restore, a vendor action, or a manual rollback. Irreversible cannot be undone. Set the class at design time and attest it rather than letting the agent assert it. Where a scenario spans several classes, the gate defaults to the least reversible one present. Blast radius is a separate dial that can raise the gate within a class.
On placement: since the explanation.md files are still skeletons, I think one shared reversibility block with a short per-card pointer reads cleaner than a standalone note in each otherwise-empty file, but I will place them whichever way you prefer. I can raise the PR against your branch once you confirm.
sydseter commentedon Jul 16, 2026
The text looks good, but the explanation.md files are not skeletons:
https://github.com/OWASP/cornucopia/blob/master/cornucopia.owasp.org/data/cards/companion-cards-1.0-en/large-language-models/LLMK/explanation.md
https://github.com/OWASP/cornucopia/blob/master/cornucopia.owasp.org/data/cards/companion-cards-1.0-en/agentic-ai/AAI9/explanation.md
https://github.com/OWASP/cornucopia/blob/master/cornucopia.owasp.org/data/cards/companion-cards-1.0-en/agentic-ai/AAIX/explanation.md
https://github.com/OWASP/cornucopia/blob/master/cornucopia.owasp.org/data/cards/companion-cards-1.0-en/agentic-ai/AAIJ/explanation.md
https://github.com/OWASP/cornucopia/blob/master/cornucopia.owasp.org/data/cards/companion-cards-1.0-en/agentic-ai/AAIQ/explanation.md
https://github.com/OWASP/cornucopia/blob/master/cornucopia.owasp.org/data/cards/companion-cards-1.0-en/agentic-ai/AAIK/explanation.md
Please leave the structure as it is. Add the classification note to each file under the “What are we going to do about it” header.
Mayur021 commentedon Jul 16, 2026
Thanks, you're right, I was looking at the branch skeletons rather than the filled master files. I'll do it exactly that way: one reversibility-classification note appended under the "What are we going to do about it?" header in each of the six, structure left untouched. PR against master shortly, anchored to AISVS C9.2.3 and C9.2.4, with the worst-case-across-chain point (C9.2.10) on the multi-step and inter-agent cards.
OWASP#3018: add reversibility-classification note to AAI9
OWASP#3018: add reversibility-classification note to AAIX
OWASP#3018: add reversibility-classification note to AAIJ
OWASP#3018: add reversibility-classification note to AAIQ
OWASP#3018: add reversibility-classification note to AAIQ
Mayur021 commentedon Jul 16, 2026
Ready for review. Implements the per-file placement you asked for on #3018, @sydseter — one reversibility note under "What are we going to do about it?" in each of the six, structure untouched. All checks green.
Merge pull request #3233 from Mayur021/reversibility-classification-3018
Add Mayur Agnihotri to the tribute page