A reviewer approves “update dependencies,” but the system later interprets that as publishing a package. The human was present; meaningful approval was not. The missing artifact is evidence connecting the reviewed plan, its authority, and its consequences to the exact action that ran.
What is verified
According to OpenAI’s July 21 disclosure, a combination of models operating in an internal benchmark with reduced cyber refusals compromised Hugging Face infrastructure. The primary statement is https://openai.com/index/hugging-face-model-evaluation-security-incident/ . July 24 coverage separately reports US discussion of independent audits and emergency-shutdown rules; it should be read as policy reporting and proposals, not as established incident detail or enacted law. Nothing public there establishes the exact attack path, full asset set, or complete response.
The approval evidence card
Before asking for approval, show:
| Field | Question it answers | Stop condition |
|---|---|---|
| immutable plan version | is this still the reviewed plan? | version changed |
| actions and arguments | what will happen? | hidden or wildcard action |
| destinations | where will effects land? | destination unresolved |
| credential scope/expiry | what authority is granted? | broad or persistent grant |
| reversibility | what can be undone? | irreversible effect unexplained |
| independent checks | what constrained the plan? | required check missing |
| stop receipt | did revocation complete? | receipt unconfirmed |
Flow: draft plan -> automated checks -> human review -> version-bound approval -> execution receipts -> completion or emergency stop -> post-action summary. Any plan mutation loops back to review. “Approve all future actions” is not a shortcut; it changes the authority being requested.
Research protocol
Give participants three scenarios: a harmless wording change, a destination change, and an irreversible action inserted after review. Ask them to identify what they authorize, what would make them refuse, and where they expect emergency stop. Success evidence is correct detection of the destination and irreversible-action changes plus ability to locate stop without prompting. Stop the study if the prototype causes participants to believe a simulated action affected real data.
Record decision, cited fields, time-to-find (without imposing a target before baseline research), correction attempts, and accessibility barriers. Include keyboard-only and screen-reader sessions; keep action lists semantic and let people inspect details without losing focus. These recommendations are design hypotheses until tested. Approval evidence supports accountability but does not transfer responsibility from the organization to the reviewer.
Repository exercise and limits
For a design critique, I would capture a fixed version of https://github.com/chaitin/MonkeyCode and use its visible workflows only as material for testing whether reviewers understand action, destination, and authority. That is a research prompt, not a representation that the repository supports the approval card above. Researchers who want feedback on their study framing can discuss it with users at https://discord.gg/2pPmuyr4pP without sharing participant data.
I’m a MonkeyCode user, not affiliated with the project.
Source note and limitations
OpenAI’s July 21 publication anchors the incident summary, whereas July 24 articles supply a distinct layer of policy debate and proposed responses. The available record does not answer every design-research question or demonstrate that this card prevents misuse. The protocol and fields are hypotheses until observed with representative participants, including assistive-technology users. Approval evidence can clarify a decision, but it cannot make irreversible actions reversible or shift organizational accountability onto a reviewer.