Add Aivist Verify to Authorization Testing - #2
Open
Aivist wants to merge 1 commit into
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This adds Aivist Verify to the Authorization Testing section, as suggested in #1. One line, following the existing numbered format.
The section already covers the observe-and-replay side well. Autorize and AuthMatrix let you see how responses differ across identities and roles, and then you judge the result yourself. Aivist Verify sits a step after that: you hand it a single candidate (one endpoint, two identities) and it adjudicates that candidate in code, returning either a confirmation with a replayable evidence chain or an honest "not confirmed". The model reads the traffic and proposes a verdict, but a deterministic gate re-checks that proposal against the attack's own bytes and can only ever downgrade it, so a confident-sounding model answer can't become a confirmation on its own.
It's a local CLI, MIT licensed, Python. I validated it against OWASP crAPI and VAmPI rather than only my own test targets, and those runs are archived verbatim in the repo. That includes one case where it produced a real false positive on crAPI's public community feed; it was fixed and re-verified against live crAPI, and the archive keeps both the original mistake and the fix. It also declines to confirm resources that every authenticated user can read, since black-box that's indistinguishable from a resource shared on purpose.
Happy to adjust the wording or drop it if it isn't a fit for the list.
Full disclosure: I'm the author.