Gate Security Course 03 | Gate & GoPlus: How to Use Tools to Defend Security in the AI Era

Security is dynamic, not static. Among the crypto projects that have been compromised through their code, quite a few had been audited by major firms. Of course, this doesn't mean audits are useless—it means the questions an audit can answer are narrower than most people assume.

Contracts get upgraded, permissions get changed, the oracles and cross-chain bridges they depend on shift, new attack techniques emerge every week—and that report is still frozen on the day it was delivered. AI has magnified this contradiction. Attackers can now scan a contract in minutes and batch-recheck old code deployed years ago that no one maintains anymore. If defenders are still stuck on "get an audit before launch," the gap will only widen.

This is the third installment of Gate's special series, "The Gate Security Course." We invited Web3 security service provider GoPlus Security and the Gate security team to discuss, from the perspectives of a security service provider and a trading platform, the new changes in crypto security in the AI era: why audited projects still get hacked, who is moving faster on offense and defense, and how ordinary users can use tools to avoid risk before signing.

Guest Introductions

GoPlus Partner Adam: Adam is a partner at GoPlus and head of its security research institute.

GoPlus Security is building the first decentralized security layer for Web3 and AI, leveraging blockchain and cutting-edge AI security solutions to provide users with intelligent, efficient, and decentralized security products and services. Since 2022, GoPlus has achieved exponential growth, reaching 30 million daily API calls and preventing nearly $100 billion in potential losses for users.

Gate Security Team: Gate's security department is responsible for building the platform's account, trading, and asset security systems, and also handles user appeals and assistance requests related to abnormal accounts on an ongoing basis.

Founded in 2013, Gate is the industry's first trading platform to launch 100% proof of reserves and currently serves over 60 million users worldwide. For us, security is not an add-on feature—it is the precondition for this business to exist at all. Through "The Gate Security Course," we hope to clearly explain the common mechanisms behind these real risks.

Q1. Why do many projects still get hacked or suffer permission abuse even after passing an audit?

GoPlus Partner Adam: "A one-time audit" does not equal "permanently secure." Traditional contract audit services now suffer from four structural failures:

1) Snapshot-style inspection. An audit is essentially a semi-manual inspection by audit engineers at a certain point in time, and its effectiveness depends on tool quality, individual skill, and work conditions. But contract code gets upgraded, admin permissions change, and parameter configurations are adjusted. From the moment a one-time audit report is delivered, it is already "expiring."

2) Inability to predict the future. New vulnerability types and new attack techniques keep emerging, and historical audits cannot cover future risks.

3) Uncontrolled external dependencies. Projects commonly rely on oracles, cross-chain bridges, and third-party protocols, and risk changes in these dependencies fall outside the scope of traditional audits.

4) Old contracts blowing up in clusters. Contracts deployed years ago that were "audited" at the time are now being batch-reexamined by AI for vulnerabilities, such as deep-seated flaws in Balancer and Yearn that went undiscovered for years after launch.

As for permission abuse, it happens more in the operational phase rather than in the contract code itself. Causes include: excessive Owner permissions (able to arbitrarily mint, blacklist, or pause trading), leaked admin private keys, improper multisig management, malicious proposals, and governance attacks... These are all security issues that tend to emerge during operations. Even if an audit report flags permission risks, who is watching them afterward? It cannot answer whether the operations are safe and reasonable.

Launching after a contract audit is only the starting point of security work, not the endpoint. What projects need is continuous security covering the entire contract lifecycle, not a one-time audit report.

Gate Security Team: An audit can tell users what the code can do, but it cannot tell users what the project team intends to do. This is what we feel most deeply in listing reviews. The root cause of many incidents lies in intent. A contract can be technically fully compliant, and the owner permission design can be within normal bounds, but the project team can still choose to exercise those permissions at a certain point—for example, changing trading rules, enabling a blacklist, or minting more tokens. These operations are all legitimate at the code level, and audit reports will not flag them as vulnerabilities, because they were part of the design to begin with.

So beyond technical audits, there must be another layer of constraint. Gate's approach is to conduct strict project screening and review during the listing process, while also signing non-maleficence declarations with project teams and monitoring compliance. This layer addresses exactly what audits cannot: the absence of code vulnerabilities does not mean the team will not make choices that harm user interests.

As for "who is watching afterward," listing is only the beginning for us. Gate conducts regular security audits of listed projects and continuously tracks contract status through on-chain event monitoring. Users can also check the current risk items of a given contract at any time.

On the user-facing side, we built a contract audit feature into Gate AI. When users encounter an unfamiliar contract, they can directly submit the contract address, source code file, or GitHub link and receive a structured risk report within minutes, covering more than 57 vulnerability types, with emphasis on owner permissions, blacklist mechanisms, minting permissions, and transfer taxes—the categories most often used in scams.

The starting point for building this feature was simple: audit reports are usually the project team's asset, users cannot get them, and even if they could, they would not understand them. But when a user is standing in front of the sign button, what they really need to know is the state of this contract at this moment.

Q2. With AI tools now so widely used, cybersecurity challenges have become significantly more severe. How should the industry adjust to address these AI-driven threats? What should be done right now?

GoPlus Partner Adam: First, we must acknowledge a reality: the cost of offense and defense is already severely asymmetric. The attack paradigm in which hackers use AI to efficiently mine vulnerabilities has taken shape and is spreading rapidly. Attacks have shifted from "expert manual research" to "automated assembly lines." If the defense side is still stuck on "hire an audit firm to produce a report before launch," or only calls in a security company after discovering a risk to "mend the fold after the sheep is lost," it is like using a bow and arrow against a machine gun. Using AI to fight AI is the only effective path.

The direction for industry-level adjustment is to upgrade from "one-time audits" or "calling in experts after problems arise" to "full-lifecycle continuous security." Take GoPlus DeepScan's "contract security trio" as an example—this is an actionable closed loop:

Before launch, Token security self-check: quickly self-inspect in minutes for backdoor risks such as honeypots, malicious minting, blacklists, abnormal transaction taxes, and Owner permissions;

At launch, AI contract audit: AI deeply analyzes source code, permission management, and business logic, scanning for vulnerabilities at both the syntax layer and business logic layer, and delivers a structured audit report;

After launch, continuous security monitoring and regular health checks: real-time tracking of newly discovered vulnerability intelligence, attack incidents, and risks from external dependencies (oracles, cross-chain bridges, third-party protocols), with AI continuously determining whether the project is affected and providing routine alerts. Conduct regular security health checks and continuous audits of contracts.

Four things "that should be done right now":

1) Immediately recheck legacy contracts. Contracts deployed years ago are currently the biggest "minefield," and AI auditing has pushed the cost of rechecking extremely low—a single scan takes minutes to tens of minutes, far below traditional manual audits. This is a hard requirement amid the wave of old contracts blowing up.

2) Put already-launched contracts on a regular scanning cadence. Scan once a day or once a week, using the ever-upgrading intelligence of LLMs and the continuously updated knowledge in the security knowledge base (Security LLM Wiki) to ensure you do not fall behind in the offense-defense contest.

3) Layer AI audits on top of traditional audits. The two are not substitutes but complements—"one more layer of protection, one more layer of peace of mind."

4) Embed tool-based review into exchange listing processes. Without changing the original listing workflow, use Token security self-checks plus AI contract audits to improve review efficiency. After listing, use continuous monitoring as routine risk control to reduce the probability of "something going wrong after listing."

Another noteworthy signal: in February 2026, OpenAI launched EVMbench, and GoPlus released DeepScan V1 at the same time and open-sourced the AI Auditing Benchmark. AI auditing has already moved from "concept" to the "industry standards building" stage. The earlier project teams adopt it, the earlier they enjoy the benefits of narrowing the offense-defense asymmetry.

Gate Security Team: AI makes attackers faster and makes attack scale easier to expand. They can find vulnerabilities more quickly, conduct phishing attacks at industrial scale, and use deepfakes to make social engineering harder to detect. The impact on the crypto industry is especially large because of the industry's own structure: a large part of the business, especially DeFi, operates in a manner close to modular finance, with various platforms built from shared components—contracts, software libraries, wallets, price oracles, cross-chain bridges, connectivity providers, web interfaces, and the systems used to push updates.

So beyond whether your own contract is secure, the more important question is whether every link you depend on remains reliable. If a single upstream component fails, losses propagate down the chain. Many major attacks go wrong at links earlier than protocol logic: vendors, development tools, the way software reaches users, or the process by which users approve transfers. AI lowers the cost of discovering these weak links and chaining them together for exploitation, and the barrier to this type of attack will only keep getting lower.

At the actionable level, we believe there are three things that should be done now.

1) Clearly define dependencies. Continuously maintain a dynamic inventory recording the contracts, libraries, wallets, vendors, cloud accounts, release systems, front ends, multisig wallets, admin keys, and validators you rely on, and review it regularly. This sounds very basic, but the vast majority of teams cannot do it, because dependencies grow quietly: a library introduced temporarily, a cloud account opened to meet a deadline, a key left behind by a former colleague—they were never formally recorded, and therefore never reviewed.

2) Limit the damage any single failure can cause. No individual, key, laptop, cloud login account, or vendor should have the ability to paralyze the entire system on its own. The approach is to distribute control across different personnel and systems, separate the right to propose changes from the right to execute them, and at the same time set operational limits, reserve waiting periods, and clearly define emergency stop authority. This principle is also implemented in our own asset architecture: separation of cold and hot wallets, with the vast majority of assets stored in offline multisig cold wallets, and hot wallets using multisig plus multi-party computation (MPC). Our default assumption in design is that something will eventually go wrong, so we must ensure that when it does, losses are limited to a certain range.

3) Treat websites and release processes as part of the vault. What users see and click on is itself financial infrastructure. Production builds should be reproducible and signed, and changes to websites, content distribution, domain configuration, and the software supply chain all require dual approval, time-limited access, and real-time alerts. Gate has deployed Anycast and DNSSEC on the platform side and uses encrypted transport layer protocols for all data transmission, precisely to ensure that what users access is truly our servers. This point is the easiest to overlook because it looks like merely an engineering issue, but for users, a tampered front end and a vulnerable contract have no difference in outcome.

Security resilience has no one-and-done certification. AI has shortened the time gap between discovering and exploiting vulnerabilities. Exchanges, protocols, and infrastructure providers all need to bring shared components into the scope of protection and conduct containment drills before the next cascading failure occurs.

Q3. Attackers are also using AI to find vulnerabilities. On both sides of offense and defense, which side benefits more right now?

GoPlus Partner Adam: Frankly speaking, in the short term, the attacker side currently benefits more. There are three reasons:

1) AI has greatly lowered the barrier to finding vulnerabilities. Work that once required top security researchers weeks to complete can now be run through an attack pipeline in minutes;

2) A massive amount of "audited back then" legacy contracts sits on-chain, forming a "gold mine" with enormous reserves for attackers;

3) Attack is one-way monetization. Finding "one" vulnerability is enough, while defenders must protect against "all" vulnerabilities.

But the window for defenders is opening rapidly, because applying the same AI capabilities on the defense side has equally striking effects. The AI audit engine's review of real attack incidents in 2026 produced these results:

ZetaChain (loss of about $300,000): detected in 5 minutes. WhiteEagle: detected in 402 seconds. HumaFinance: detected in 505 seconds. BoostHook: detected in 20 minutes. Token of Power (loss of about $1.5 million, a 7-year-old contract): detected in 12 minutes. JoeAgentToken: detected in 27 minutes.

It took hackers only minutes with AI to extract this money, and defenders actually also needed only minutes to find the same vulnerabilities. The only difference is whether the project team correctly used AI before the hackers did.

More critically, defenders have three structural advantages attackers do not:

1) First-mover advantage: defenders can recheck unlimited times before launch and during operations, while attackers can only bet that defenders have not done a recheck;

2) Cost advantage: AI audits are priced per scan or annually, and the cost is low enough to make continuous, full-scale auditing feasible;

3) Knowledge compounding: the security knowledge base continuously evolves with every new attack incident, and defense systems get stronger the more they are used.

So the answer is: AI itself does not favor either side. What determines the balance is who uses it first and who can use it more continuously and better. At present, attackers are temporarily half a step ahead, but we believe we can close that half-step gap very soon.

Gate Security Team: We agree with Adam's judgment. If we look only at absolute capability, attackers are indeed half a step ahead in the short term. From a trading platform perspective, we would add two observations and then look at who benefits more from another angle.

First, the changes we have seen. What AI changes most is capacity. Attackers have always scanned open-source contracts for vulnerabilities, which used to require manual analysis one by one. Now it can be processed in automated batches. The same person who could review dozens of contracts a week in the past can now scan thousands. The attack techniques themselves have not changed much; what has changed is the order of magnitude in the number of similar attacks. The impact on small projects is especially large. Problems that once slipped by because they were unremarkable are now indiscriminately scanned out.

First additional point: the defense side needs a different set of things to watch. If you only watch for abnormal transfers, you cannot keep up with attacks in the AI era, because attacks often begin long before funds move. You also need to watch earlier signals such as changes in key control, sudden upgrades, abnormal system behavior, unusual cloud logins, unexpected website launches, software version drift, and abnormal withdrawals. In addition, various limits, kill switches, and response playbooks only truly work if the team has rehearsed them before a crisis occurs. An emergency stop button that has never been pressed often leaves no one willing to press it when something actually goes wrong.

Second additional point: the incentive direction of bug bounties also needs adjustment. Most bounty programs in the industry currently target single-point vulnerabilities, while what AI is best at is precisely chaining multiple unremarkable weaknesses together. So it is worth supporting composite vulnerability bounties and rewarding researchers who can demonstrate how the front end, libraries, cloud services, signing processes, governance mechanisms, and contracts fail in coordination. Gate itself has also long operated a bug bounty program and welcomes security researchers worldwide to submit findings.

Finally, let us answer who benefits more from another angle. The old asymmetry was that attackers were professionals and users were amateurs. An ordinary user preparing to participate in a new project had almost no judgment tools at hand and could only rely on intuition and what others said; professional audits are priced by project from thousands to tens of thousands of dollars, which for ordinary users is equivalent to not existing. Now the same users can obtain a structured risk report within minutes. This change means little to attackers because they already had the capability; it means a great deal to users because they originally had nothing.

So if we look at "how much the originally weakest side gained," we believe the biggest beneficiary is the defense side, especially ordinary users. Adam said that half-step gap can soon be closed, and we believe so too. The key to closing it lies in whether users are willing to spend those extra few minutes before interacting.

Q4. What should a complete audit report include? How should the security score, key findings, and remediation recommendations each be used?

GoPlus Partner Adam: An audit report that can guide action (rather than just sit in an archive) should contain at least four elements:

1) Security score (a quantifiable rating), used for "quick screening," not for a "final conclusion." Project teams can use the score as a quantitative anchor for internal security assessment and compare changes after each iteration; exchanges can use it for initial listing screening to keep clearly substandard projects out