On June 25, the controversy regarding Anthropic's model security, access control, and capability leakage has escalated once again.
Written by: CoinW Research Institute
On June 25, the controversy regarding Anthropic's model security, access control, and capability leakage has escalated once again. Anthropic publicly accused Alibaba of systematically extracting information related to the Claude model's capabilities through nearly 25,000 fraudulent accounts. This accusation complicates the already hampered recovery process of Fable 5 and brings a core issue to the forefront again: as cutting-edge models exhibit stronger cybersecurity, code analysis, and automation capabilities, model access, account risk control, cross-border use, and capability leakage will all fall under the regulatory and platform governance framework.
To understand this controversy, we need to rewind the timeline to June 12. On that day, Claude Fable 5 and Mythos 5 under Anthropic were abruptly suspended from access, quickly attracting attention from the AI industry and the crypto market. Fable 5 was initially an open model in the Mythos class, overlaid with security restrictions to reduce its abuse potential in high-risk areas such as cybersecurity and biosecurity; however, after a bypass path for these security protections was discovered, the U.S. government restricted access to the related models for foreign nationals through export controls, and Anthropic subsequently expanded the access restrictions to all users. Almost simultaneously, Microsoft temporarily restricted internal employees from using the model due to Fable 5's data retention requirements. This series of reactions indicates that corporate clients' concerns have extended beyond the model's capabilities to issues such as data retention, internal code, and protection of trade secrets.
Afterwards, the expectations for the recovery of Fable 5 continued to fluctuate. On June 18, U.S. government officials requested Anthropic to prove that its security protections could not be bypassed before re-releasing the model; on June 22, relevant API documentation pages reappeared in search results, but the actual access entry had still not been restored. Polymarket's predictions indicate that the market is still betting on the eventual restoration of Fable 5: the probability of it being operational in the U.S. by the end of July is about 90%, and by the end of August, about 94%. This repetition itself suggests that access to cutting-edge AI is no longer merely about whether a product is online or offline, but rather is the result of the interplay among security proofs, policy judgments, and platform executions.
Source: https://polymarket.com/event/claude-fable-5-restored-for-us-customers-by-20260613193753196
It can be seen that the key to the Fable 5 ban incident lies not in when a specific model regains access, but in the structural boundaries of centralized cutting-edge AI being revealed: the stronger the model capabilities, the more likely they will be simultaneously constrained by security reviews, export controls, corporate data compliance, and platform permissions. For the crypto industry, this provides an opportunity to reconceptualize DeAI. The significance of decentralized AI is to attempt to weaken the control that a single platform has over model access, data processing, and execution processes through open computing, distributed reasoning, on-chain incentives, privacy computing, and verifiable execution. Along this line, the following CoinW Research Institute will first recap the Fable incident, then subsequently analyze the three types of gaps in centralized AI, the issues that DeAI can address, the three technical paths for verifiable AI computation, and the differentiation of representative projects across different infrastructure layers, before returning to the realistic boundaries and long-term opportunities of DeAI.
1. Recap of the Fable Incident: Not a Simple Model Downtime
Main Line of the Event: Amazon Researchers Discover Bypass Pathways
The sensitivity of Fable 5 and Mythos 5 comes from their capabilities in cybersecurity tasks. Mythos 5 is mainly open to selected partner institutions for identifying and fixing software vulnerabilities; Fable 5, on the other hand, is a more broadly released public version that retains some Mythos-level capabilities while using security restrictions to prevent it from producing harmful content.
The problem occurred with this layer of security restrictions. Public information indicates that Amazon researchers discovered bypass pathways in the Fable 5 safeguards during testing, leading Amazon CEO Andy Jassy to express concerns to the White House. Subsequently, senior officials from the White House engaged in multiple rounds of communication with Anthropic CEO Dario Amodei within 24 hours, requesting the company to proactively take the model offline and address the vulnerabilities. Anthropic believed that the relevant bypass methods were closer to localized issues and did not constitute widespread "jailbreaking"; however, the White House opined that the security risks were sufficient to trigger national security-level intervention.
The U.S. government subsequently implemented export controls on Fable 5 and Mythos 5, prohibiting foreign nationals from using the related models. Due to Anthropic’s difficulty in quickly verifying the nationality and identity of all users, the company ultimately suspended access for all customers. This step transformed the Fable incident from a model security controversy into an access rights issue in cutting-edge AI.
Detail One: Dual Uses of Mythos-Level Capabilities
The core of the Fable controversy does not lie in general Q&A but rather in the increasingly blurred boundaries between "defensive capabilities" and "offensive capabilities". Cybersecurity models can help companies identify vulnerabilities and fix systems, but they can also assist attackers in finding entry points and automating the exploitation of flaws.
This was also the reason for the government's swift intervention. If a model can only write copy or generate code, regulatory pressure is relatively limited; however, once it possesses strong vulnerability discovery and exploitation capabilities, it is repriced within the national security framework. Fable 5, as a public version, aimed to reduce risks through its safeguards; when those safeguards can be bypassed, what regulators see will be "potentially open high-risk capability entry points".
Detail Two: Microsoft's Restrictions Reveal Corporate Risks
Another clue in the Fable incident comes from Microsoft. Microsoft temporarily restricted employee access to Claude Fable 5 due to Anthropic's new data retention requirements. The prompts and outputs from Fable 5 can be retained for 30 days, and content flagged by the security system can be kept for a longer duration. Microsoft is concerned that employees might input customer data, company files, or internal code during usage, and if relevant content is retained and enters the investigative process, it could pose compliance and competitive risks.
This detail is very crucial. It indicates that the risks associated with cutting-edge AI have expanded from "Is the model dangerous?" to "Can companies control their own data?". When enterprises use AI, their concerns are not just whether the model answers are good enough, but also whether the prompts are stored, whether data can be deleted, whether model calls comply with internal regulations, and whether vendors might have access to sensitive content during security investigations.
Detail Three: Export Controls Trigger Discussions on AI Sovereignty
The Fable incident has also sparked a broader discussion on AI sovereignty. The core of market skepticism is: while the U.S. government hopes to promote American AI abroad, it can also cut off foreign access to cutting-edge models via export controls, which forces global clients to reassess the reliability of U.S. AI supply.
This means that the impact of the Fable incident will not be limited to Anthropic. Companies, nations, and developers need to rethink the AI supply chain: if core models come from a small number of U.S. companies, is access stable; if enterprise workflows heavily rely on a specific model, will policy changes lead to business interruptions; if security and compliance rules are determined internally by platforms, can external users obtain sufficient evidence?
Thus, the Fable incident is no longer a standalone model downtime event. The real reason it triggers discussions on DeAI is that the three types of structural gaps existing in centralized AI are simultaneously amplified: access rights are determined jointly by platforms and regulators, data flows remain within the platform, and there is a lack of externally verifiable evidence throughout model execution processes.
2. Gaps in Centralized AI: Access, Data, and Executions Are Unverifiable
Uncontrolled Access: Model services can be cut off by external rules
The Fable incident proves that cutting-edge models are no longer simply ordinary internet services. They are influenced by national security, export controls, identity verification, partner feedback, and geopolitical relationships. Once enterprises integrate R&D, code audits, risk controls, customer service, or automation tasks into a single model, a sudden suspension of the model can turn into a business continuity issue.
This type of risk has been underestimated by the market in the past. Users often only compare model capabilities, prices, and response times, rarely taking "Will the model suddenly become unavailable?" into evaluation. After Fable was pulled, this risk was presented in reality. In the future, when enterprises choose AI vendors, they may consider redundancy solutions, backup models, and the ability to switch across vendors just like choosing cloud services.
Data Visibility: Enterprises find it hard to ascertain how sensitive information is processed
The core of Microsoft's limitation on Fable 5 lies in data retention. The stronger the model, the more likely it may be connected to source code, client information, financial documents, strategy documents, and internal knowledge bases. At this point, whether prompts and outputs are retained, how long they are retained, who can access them, and whether they will be used for security investigations will all become key factors for enterprises considering model integration.
Centralized AI services typically keep these processes within the platform. Users can only read policy terms and find it difficult to verify technically whether data has actually been deleted, whether it has entered a certain classifier, or whether it has been accessed by a certain investigative process. Enterprises need clearer privacy statements and evidence of execution that can be externally verified.
Execution is Unverifiable: Whether the security layer is indeed effective is hard to judge externally
The controversy around Fable also centers on the security layer. The model claims to have restrictions in place, but whether those restrictions are correctly executed each time is difficult to validate for external users. Model versioning, system prompts, routing mechanisms, security classifiers, and output filters are all handled internally by the platform. Users see the answer but cannot view the execution path behind it.
In low-risk scenarios, such opacity may be acceptable; in finance, cybersecurity, code audits, on-chain transactions, and asset management, it will become a liability issue. Users need to know whether the model has been replaced, whether the execution environment is trustworthy, whether inputs or outputs have been tampered with, and whether AI Agents have overstepped their bounds. The structural gap of centralized AI lies here: capabilities are becoming stronger, but external verifiable mechanisms have not matured in sync.
Thus, the questions that DeAI needs to address become more specific: In cases where model access may be cut off, are there alternative entry points; when sensitive data must enter model workflows, is there a demonstrable processing environment; when AI Agents begin executing transactions, calling contracts, and managing permissions, can a traceable evidence chain be maintained? The importance of verifiable AI computation begins to manifest at this level.
3. What Can DeAI Solve: From Open Access to Trusted Execution
The reason the Fable incident resonated within the crypto industry is that it touches on a familiar issue: can critical infrastructure be shut down by a single entity. The core value of Bitcoin lies not just in asset prices, but in providing a global, permissionless, and censorship-resistant value transfer network. AI is becoming a new critical infrastructure, and as model capabilities begin to influence code, security, corporate processes, and asset execution, the market naturally starts to ask: Is there a need for a more open, swappable, and verifiable AI access and execution layer?
This does not mean that all AI must be trained through decentralized networks, nor does it imply that technology can completely circumvent regulation. A more realistic judgment is that users will require two types of capabilities: one type is the strong intelligence provided by centralized cutting-edge models, and the other type is the access redundancy, privacy protection, and verifiable execution offered by open networks. When models like Fable are suddenly suspended due to policies or platform rules, the market will reconceive the demand for permissionless AI. Currently, the value of DeAI is primarily reflected in the following three areas:
Solving Single Point Access: Reducing dependence on a single model supplier
DeAI can first alleviate the single point access problem. The Fable incident illustrates that cutting-edge models can be abruptly severed by policies or platform rules. Specifically, on the product level, DeAI can reduce risks through three methods: first, introducing multiple model routing to allow users to switch between centralized models, open-source models, and decentralized reasoning networks; second, creating an open model market that allows various models and reasoning services to freely connect, thereby lowering the control of a single supplier; third, utilizing privacy reasoning entry points and local model combinations to maintain backup routes for users in critical tasks.
In the short term, DeAI may not be able to train another Claude. A more realistic value is to ensure that critical workflows are no longer entirely reliant on a single model entry. For average users, this means access choices; for enterprises, this means business continuity; for nations and regions, this is a part of AI sovereignty.
Solving Data Trust: Allowing sensitive computations to run in verifiable environments
The second value of DeAI is to enhance the verifiability of sensitive computations. When enterprises and on-chain applications invoke AI, they often involve confidential data, code, transaction strategies, or user assets. Trusted execution environments, remote proofs, privacy computing, and on-chain auditing allow users to confirm whether sensitive data is being processed within a protected environment.
The emphasis of this path is to enable users to obtain evidence about the execution environment without exposing their privacy. For instance, enterprises can demand that AI reasoning occurs within trusted execution environments and can use remote proofs to confirm the running code and model versions; on-chain applications can record task hashes, execution results, and proofs on-chain; users can verify, without disclosing raw data, that the computing environment has not been randomly replaced. This is more important than merely pursuing stronger models for finance, healthcare, corporate compliance, and on-chain asset management.
Solving Execution Responsibility: Leaving evidence chains for AI Agent actions
The third value of DeAI is to establish chains of responsibility for AI Agents. In the future, AI Agents will invoke wallets, exchanges, cloud services, enterprise systems, and on-chain contracts. They will transition from answering questions to directly executing tasks. At this point, the market will need not only model outputs but also execution logs, permission records, calling paths, fund flows, and error accountability mechanisms.
On-chain systems are more suitable for recording these actions. Through on-chain logs, collateral, challenge mechanisms, and economic penalties, DeAI can transform AI execution from "platform backend operations" into traceable, verifiable, and accountable behavior. For example, each time an Agent calls a contract, reads data, initiates a transaction, or submits results, it can leave an auditable record; if a node submits incorrect results, it can be re-examined and penalized through a challenge mechanism. The true demand propelled by the Fable incident is precisely this layer of requirement.
4. How DeAI Establishes Trusted Execution: Three Paths for Verifiable AI Computation
From existing projects and research paths, verifiable AI computation is not a single technology but is a combination of solutions centered around "operating environment, computation results, execution behavior." Different paths address different issues, and their deployment rhythms also vary.
Verifying Operating Environment: First confirm where the model is running
The first path is trusted execution environments, with the core goal of proving that models run in a protected hardware environment. Users do not need to see the backend servers but can use remote proofs to confirm that the code, model, and execution environment have not been arbitrarily altered. This type of solution is more aligned with real-world applications and suitable for enterprise private models, AI Agent executions, financial risk controls, and on-chain automation tasks.
Its advantage lies in relatively controllable costs and delays, which can first address the questions of "Where does the model run?" and "Is data processed in a protected environment?". The limitation is that it still relies on hardware vendors, trusted execution environments, and remote proof mechanisms. If the underlying hardware or proof mechanisms fail, the verification foundation will also be affected.
Verifying Computation Results: Making AI outputs carry evidence
The second path is cryptographic proofs, commonly including zero-knowledge proofs and zkML. Its goal is to generate a verifiable computation certificate for AI computations, allowing third parties to confirm that results indeed come from specified computational processes without re-running the entire model.
This path is closer to a "mathematical proof." Its advantage is stronger determinism, suitable for scenarios with extremely high correctness requirements; its limitation is the high cost and delay of proof generation, and it still has limited support for large cutting-edge models. Lightweight verifiable reasoning research is beginning to explore cost reductions using sampling and commitment mechanisms, but transitioning from research to large-scale commercial use still requires time.
Verifying Execution Behavior: Making errors and overstepping costly
The third path involves economic incentives and auditable logs. It does not require each AI reasoning to generate a complete proof immediately. The core is to impose costs on erroneous results and malicious behavior through challenges, recalculations, sampling validations, collateral penalties, and on-chain records. Nodes submitting false results may have their collaterals forfeited, and parties identifying errors can receive rewards.
This path is especially important for AI Agents. In the future, users will need to consider not only the model outputs but also which interfaces the Agent invoked, what permissions were used, whether there was overstepping, and whether actions were executed as authorized. Auditable logs transform AI behavior from backend operations into a record that can be tracked, and they may land sooner than full verifications of large models.
5. Representative Projects: DeAI is Differentiating into Different Infrastructure Layers
Along the three verification paths outlined above, DeAI projects are beginning to differentiate into various infrastructure layers: Bittensor and Gensyn lean more towards intelligent supply networks, Venice more towards user access, while OpenGradient and Ritual are closer to the layers of verifiable computation and on-chain execution. The differences among these projects also indicate that DeAI is forming a composite ecosystem around access, privacy, proof, and execution.
5.1 Bittensor: Filtering Machine Intelligence Supply with Subnets
X: https://x.com/opentensor
As one of the early decentralized AI networks with a larger ecosystem scale, Bittensor represents the open intelligence market route. It consists of numerous subnets, each of which is a relatively independent machine intelligence market: miners are responsible for producing digital goods, covering computing power, storage, AI reasoning, training, financial predictions, and more; validators assess the quality of outputs produced by miners; subnet creators design incentive mechanisms; and TAO holders can support validators by staking. The network eventually distributes TAO incentives to participants deemed to contribute more.
In terms of capital structure, Bittensor differs from typical equity financing projects. It has not conducted traditional private placements or ICOs; the core protocol is maintained by the Opentensor Foundation, and TAO does not have reserved shares for early investors. However, this does not mean an absence of capital: Polychain participated in incubating Bittensor as early as 2019 and has accumulated approximately $200 million in TAO positions through secondary markets and mining and validation processes; Digital Currency Group has continuously purchased through its subsidiary Yuma, temporarily becoming the largest holder, with holdings of about 500,000 TAO, accounting for approximately 2.4% of the total.
From the on-chain activity perspective, the Taostats subpage shows that the total trading volume in the Bittensor subnet market is approximately 193,300 TAO in 24 hours, with trading volume for individual subnet Alpha Tokens (the native tokens corresponding to each subnet, used to reflect market pricing, staking, and capital flow for specific subnets) being about 139,000 TAO, accounting for 71.93%; Root TAO (the native TAO asset of the Bittensor mainnet, serving as the base asset for entering and exiting various subnet Alpha Tokens) sees a trading volume of about 54,300 TAO, accounting for 28.07%. This indicates that current trading activity is mainly driven by specific subnet assets rather than the mainnet TAO side.
Source: https://taostats.io/subnets
Currently, prominent representatives among the subnets include SN3 τemplar and SN64 Chutes: SN3 τemplar focuses on decentralized large model training, with its team having completed the training of the 72B parameter model Covenant-72B on Bittensor Subnet 3, representing Bittensor's training capability; SN64 Chutes focuses on serverless AI reasoning, having processed over 9.1 trillion tokens with daily peaks exceeding 50 billion tokens, making it a prominent subnet for reasoning usage. Meanwhile, CoinW has launched a TAO ecosystem area and has first released the Chutes-SN64, Gradients-SN56, and Targon-SN4 subnets.
Bittensor has expanded from a single AI network to an open intelligence market with multiple tasks, assets, and incentive curves coexisting, decomposing different digital goods such as AI reasoning, training, data, financial predictions, computing power, and storage into independent markets driven by miners’ supply, validators’ assessment, and token incentive distribution.
What's worth noting is that some reasoning subnets have begun to enhance result evaluation and verification layers. The "verification" here is closer to a quality filtering mechanism within the network: miners submit model outputs or task results, validators judge quality through scoring, backtesting, sampling reviews, benchmark tasks, and incentive rules, ultimately affecting the TAO incentives miners receive. Bittensor's value lies in transforming "Who can provide intelligent services" into an open competitive issue, with the difficulty being that quality disparities among different subnets are significant, and the standards for verification and anti-cheating mechanisms determine whether the network can truly filter out high-quality AI services.
5.2 Venice: User-Side Privacy AI Access
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
