Gains:
- Ability to understand that artificial intelligence expands the scope of the auditor, but does not replace it, and is useful in category scanning and finding drafting.
- Being able to recognize that artificial intelligence has missed the original vulnerability and business logic error, and that a fluent 'secure' statement is not assurance
- Ability to classify findings according to their level of seriousness and understand that the final approval and professional responsibility rests with the competent auditor.
Security audit (systematic examination of a smart contract for vulnerabilities) is Web3's most responsible job. A single line missed by an auditor can result in millions of dollars in losses. In this unit you will learn how to use AI as an audit assistant; We will learn from generating clues to writing a findings outline. But the most critical sentence is this: AI does not control; It is an assistant that sharpens the auditor's eye. The final approval lies with the competent auditor who assumes professional responsibility.
Why auditing is security-critical
An audit report reassures the project and investors that “this code has been reviewed.” If this assurance is false, the consequences are disastrous: exploited protocol, lost funding, collapsed project. Therefore, the use of AI in inspection is the most careful part of this module. AI expands the scope of the auditor (recalls more patterns, reads faster) but does not replace the auditor.
Why doesn't it pass? Because:
- AI cannot see the unique/new vulnerability that is not in the training data.
- AI often misses the flaw in the protocol's business logic—that the code is technically correct but economically exploitable.
- AI can give false reassurance by saying “safe” in fluent language; This is the most dangerous outcome.
Layers of using AI in control
1. Initial scan and pattern reminder. AI goes through known vulnerability patterns like a checklist: reentrancy, access control, oracle manipulation, front-running. This ensures that the auditor does not miss any categories.
2. Code explanation. Explaining a complex function to the AI in plain language allows the auditor to quickly grasp the logic; but the description is always compared to the code.
3. Writing a draft of findings. When the auditor finds a vulnerability, AI saves time in writing the draft of the report (description, impact, proposed solution).
4. Generating counter-hypothesis. Ask the AI "how can this function be abused?" Asking " reminds us of the aggressive perspective.
Attention: Just because the AI says "I did not find any vulnerabilities in this code" does NOT mean "this code is safe". Evidence of absence is not absence of evidence. The fact that the AI cannot find something does not make it unnecessary for the auditor to examine that area.
Finding severity levels
Audit findings are classified according to their severity level. AI should use this framework when generating drafts:
Level
Meaning
example
critical
Fund loss/lockout directly possible
Withdrawing funds with reentrancy
high
Serious impact in certain conditions
Unauthorized printing (mint)
medium
Limited impact or difficult condition
Small loss with Oracle deviation
low
Minor risk, breach of good practice
Missing event broadcast
Information
Non-security, readability
Lack of NatSpec
Weak prompt / Strong prompt
Weak prompt:
Is this contract safe?
This question forces the AI to make an absolute, unwarranted judgment like “yes/no” — exactly what we don't want.
Powerful prompt:
Your role: assistant to senior smart contract auditor.Scan the following contract for security. Go through the following categories one by one: reentrancy, access control, integer operations, input validation, oracle/external data, front-running, gas limit. For each FINDING: (1) relevant line of code, (2) cause risk, (3) estimated severity (Critical/High/Medium/Low), (4) solution proposal. These are HYPOTHESES TO BE CONFIRMED; Do not give a "safe" verdict. Mark the areas you are not sure of clearly saying "let the auditor confirm".
Four copyable templates
1) Category based browsing:
Scan this contract for the following categories: reentrancy, access control, integer overflow, input validation, oracle dependency, front-running, DoS/gas. For each category, say "there is/is no risk/I'm not sure" and connect your justification to the line in the code. Don't make a final judgment.
2) Counter-hypothesis from the attacker's perspective:
Think like an attacker: what are the ways to abuse this function? Write each scenario step by step and indicate what conditions are required. These scenarios are the hypotheses to be tested; DO NOT generate actual exploit code, just describe the risk.
3) Draft findings report:
Report the following verified finding in formal audit language: title, severity, description, impact, affected code, steps to reproduce, proposed solution. Use measured and technical language; exaggeration. Assume the finding is confirmed by the auditor, do not make up a new finding.
4) Fix verification:
Below is a vulnerability and the fix applied by the developer. Examine whether the fix actually closes the vulnerability; mark whether it creates a new side effect or vulnerability. Don't say "closed" for sure; End with "must be confirmed by testing".
Three mini cases (in numbers)
Case 1 — AI prevented category hopping. An auditor was about to focus on a 400-line contract and skip the oracle category. AI's category scan gave a warning that "price data is from a single source, open to manipulation". The auditor examined it and found that it was indeed a medium risk. Lesson: AI maintains coverage discipline.
Case 2 — False “safe” assurance. Another team asked the AI “is this safe?” he asked; "There doesn't seem to be a significant problem," AI said. The crew inspection was light. Then the independent auditor found a business-logic flaw: a calculation that was technically correct but whose incentives were exploitable. Lesson: AI misses business logic error; He can't be trusted to say "safe".
Case 3 — Drafting the report saved 3 hours. The auditor was spending half the day manually reporting 8 findings. Once I gave the verified findings to the AI and printed the official draft, the time dropped by ~3 hours; The auditor devoted time to deepening. Lesson: AI is safe and efficient in reporting because the findings have already been humanly verified.
Business logic vulnerability: AI's blind spot
The most expensive vulnerabilities often come not from a technical error in the code, but from the exploitability of the business logic: rounding exploitation of a reward account, flash loan hijacking of a vote, instantaneous manipulation of a price. These are cases where the code works "correctly" but the protocol can be tricked economically. AI is likely to miss such errors—especially protocol-specific ones. Therefore, business logic review is the most human-intensive area of the auditor and the least reliant on AI.
Hint: Ask the AI “how can the economic incentives of this protocol be exploited?” and use the scenarios that come up as a starting point — but remember that you and your team should do the real analysis.
Common mistakes
- Ask the AI "is it safe?" Asking and trusting your yes. Absolute judgment is not required.
- Stopping the review when the AI says "I couldn't find it". Absence is not evidence.
- Delegating business logic review to AI. It is his biggest blind spot.
- Not using independent tools (Slither etc.). AI alone is not enough.
- Putting the finding made up by the AI into the report without verifying it. Risk of hallucinations.
- Trying to put control responsibility on AI. The responsibility lies with the expert.
In summary
- Audit is safety-critical; AI expands the auditor's scope but does not replace it.
- AI misses the original vulnerability and business logic bug; Saying "safe" is not assurance.
- Findings are classified according to severity level; AI is useful in generating drafts.
- Counter-hypothesis and category screening preserve the discipline of inclusion.
- Final approval and professional responsibility always lies with the competent auditor.
Application task
Find a sample contract that contains a known vulnerability (for educational purposes, examples of "vulnerable contracts" are available in open source). Apply the "category based scanning" prompt to the AI. Note whether the AI: (1) found the real vulnerability, (2) produced fabricated/false findings, (3) made absolute judgments such as “secure.” Then compare it with a static analysis tool.
checklist
- [ ] Ask the AI "is it safe?" Instead, I had a category-based scan.
- [ ] I treated each finding as a hypothesis.
- [ ] I did the business logic review myself/team.
- [ ] I cross-validated it with an independent static analysis tool.
- [ ] I have confirmed that the AI does not fabricate findings.
- [ ] I classified the findings according to the level of severity.
- [ ] I accepted that the final approval lies with the competent auditor.