aitoolsblocklist

A lightweight, production-ready Python client for AI blocking: a daily-refreshed database of classified AI-tool domains built for web filtering, DNS security, data-loss prevention and acceptable-use enforcement. The package wraps the API in a small, typed, dependency-light interface so security engineers, network administrators and compliance teams can look up AI-tool domains, read the vendor's data-use terms and download the feed database directly from Python.

The underlying dataset is a specialized extraction from a 120-million-domain enterprise web filtering infrastructure. It contains 20,000+ AI-tool domains, chatbots, code assistants, image and video generators, voice-cloning services, autonomous agents, AI companions and more, each classified into functional categories and subcategories rather than a single flat "AI" label. That granularity is what makes per-category policy possible: permit an approved AI tutor while blocking a deepfake generator, or allow a coding assistant while flagging an unvetted document-processing service. Every record also states whether the vendor trains on customer input, with the date the terms were checked.

---

Installation

pip install aitoolsblocklist

The only runtime dependency is requests. Python 3.7 and newer are supported.

Quick start

from aitoolsblocklist import AIToolsBlocklistClient

client = AIToolsBlocklistClient("YOUR_API_KEY")

# Single lookup: is this domain an AI tool, and what kind?
result = client.lookup("chatgpt.com")
print(result["blocked"])             # True
print(result["primary_category"])    # "Text & Language"
print(result["ai_type"])             # "ai_native"
print(result["categories"])          # [{"category": "Text & Language", "subcategory": "General assistants & chatbots"}]
print(result["trains_on_data"])      # "opt_out_default"
print(result["terms_checked"])       # "2026-09-17"

# A convenience boolean for policy gates
if client.is_blocked("midjourney.com"):
    enforce_block_policy("midjourney.com")

An API key is issued in the account area after subscribing to any plan and is sent as the X-API-Key header on every request. One lookup is charged per lookup() call. The public methods stats(), taxonomy() and clause() need no key.

Technical overview

Authentication and configuration

client = AIToolsBlocklistClient(
    api_key="YOUR_API_KEY",
    base_url="https://www.aitoolsblocklist.com",  # default
    timeout=30,        # per-request timeout, seconds; downloads use at least 300
    max_retries=3,     # automatic backoff on 429, 503 and network errors
)

Transient failures, HTTP 429 and 503, are retried automatically with exponential backoff, honoring the Retry-After header when present. Authentication problems raise immediately, because retrying a revoked key is pointless.

Endpoints and methods

Method	Endpoint	Key	Purpose
lookup(domain)	GET /api/check?domain=	yes	Classify one domain
is_blocked(domain)	same	yes	Convenience boolean
bulk_lookup(domains, pause)	same, sequential	yes	Deduplicated lookups, {"results": [...]} in input order
bulk_lookup_all(domains, pause)	same	yes	The flat list
data_use(domain)	same	yes	The five vendor data-use fields
stats()	GET /api/stats.php	no	Totals and the 18 categories with counts
taxonomy()	same	no	{name: {total, subcategories}}
clause(domain, field)	GET /api/data-use-clause.php	no	Verbatim vendor clause with URL
database_status()	GET /api/database/?action=status	feed or database plan	Plan and file state
database_info()	GET /api/database/?action=database_info	feed or database plan	File name, timestamp, size
download_database(path)	GET /api/database/?action=download_database	feed or database plan	Stream the full CSV to disk
download_categories(path)	GET /api/database/?action=download_categories	feed or database plan	Stream the category tree CSV

Lookups

Pass a bare domain, chatgpt.com, or a URL; the client strips the scheme, path and a leading www.. Subdomains resolve to their registrable domain, so chat.openai.com returns the classification for openai.com. Both found and not-found responses are HTTP 200; your integration checks one unambiguous blocked boolean instead of distinguishing "not found" from "bad request."

report = client.bulk_lookup(["openai.com", "github.com", "notion.so"], pause=0.05)
for row in report["results"]:
    print(row["domain"], row["blocked"], row.get("primary_category"), row.get("trains_on_data"))

A found record:

{
  "domain": "chatgpt.com",
  "blocked": true,
  "primary_category": "Text & Language",
  "ai_type": "ai_native",
  "categories": [{"category": "Text & Language", "subcategory": "General assistants & chatbots"}],
  "trains_on_data": "opt_out_default",
  "opt_out_available": "yes",
  "enterprise_no_training": "yes",
  "api_no_training": "yes",
  "terms_checked": "2026-09-17",
  "quota_remaining": 9999986
}

Data-use values are yes, no, opt_out_default or unstated. ai_type is ai_native for tools that are the AI and ai_enabled for products with an AI feature inside. A domain that is not an AI tool returns blocked: false with an empty categories list.

Loading the full list

For a local cache, DNS sinkhole or firewall External Dynamic List, feed and database plans download the classified CSV and match locally:

info = client.database_info()
print(info["database_file"], info["last_updated"], info["file_size_human"])

client.download_database("/var/lib/atb/ai_tools_full.csv")
client.download_categories("/var/lib/atb/ai_tools_categories.csv")

import csv
blocked = {row["domain"] for row in csv.DictReader(open("/var/lib/atb/ai_tools_full.csv", encoding="utf-8"))
           if row["primary_category"] in {"Image & Visual", "Audio & Voice"}}

A nightly cron re-downloads the file after the daily rebuild. This "download once a day, match locally" pattern lets a modest plan back millions of local lookups, because the actual matching happens in your own Redis, SQLite or flat file. Hosted feeds in EDL, PAC, hosts and DNS formats are also available in the account area for firewalls and resolvers that fetch their own lists.

Vendor terms, verbatim

c = client.clause("chatgpt.com", "trains_consumer_default")
if c:
    print(c["clause"], c["url"])

Fields: trains_consumer_default, optout_available, enterprise_no_training, api_no_training. The response is the sentence from the vendor's terms and the page it came from, which is what an approval ticket needs.

Error handling

The client raises a small, specific exception hierarchy so callers can react precisely:

from aitoolsblocklist import (
    AIToolsBlocklistError, AuthenticationError, QuotaError,
    PlanError, RateLimitError, NotFoundError,
)

try:
    result = client.lookup("example.com")
except AuthenticationError:
    ...   # 401: rotate or renew the key
except QuotaError:
    ...   # 403: inactive account or monthly quota exhausted
except PlanError as exc:
    ...   # 403 on the database endpoints: lookup-only plan, exc.body["plan"] names it
except RateLimitError:
    ...   # 429 after retries: back off or upgrade the plan
except AIToolsBlocklistError:
    ...   # any other API or network failure

The client is also a context manager, so the underlying HTTP session is cleaned up automatically:

with AIToolsBlocklistClient("YOUR_API_KEY") as client:
    print(client.stats()["total_tools"])

---

Why domain-level AI classification is needed

The technical interface above solves a problem that has become urgent for nearly every organization that runs a network: you can no longer see, let alone govern, where your data goes when employees and students use AI tools.

Two years ago, "AI at work" meant a handful of well-known services. Today, thousands of AI products launch every month, each with its own domain, and each capable of receiving text, code, images or documents that a user pastes in. A blanket firewall rule cannot keep up, and a hand-maintained list of the famous fifty tools is stale within a week. The result is shadow AI: unsanctioned tools processing sensitive information with no oversight. Surveys of enterprise security leaders consistently rank data exposure through generative AI among their fastest-growing risks, and the guidance emerging from public research institutions reflects the same concern.

The data-governance problem

When an employee pastes a customer contract into an unfamiliar AI summarizer, or a developer sends proprietary source code to an online "explain this function" tool, that data leaves the organization's control. It may be logged, used for model training, or retained indefinitely. This is not a hypothetical: the U.S. National Institute of Standards and Technology's AI Risk Management Framework explicitly identifies data confidentiality and third-party dependency as core risks to be mapped and managed, and encourages organizations to maintain an inventory of the AI systems their people actually use. You cannot inventory what you cannot see, and you cannot see AI-tool usage at the network layer without knowing which of the millions of domains crossing your egress are AI tools in the first place.

Foundational work on the risks of large-scale models, for example open-access research from academic and industry labs, has documented how readily these systems memorize and can surface training data, which is precisely why unsanctioned data submission matters. Domain-level classification is the practical control point: it turns an unbounded, ever-changing population of AI services into a queryable list your existing security stack can act on, and the training-terms fields on each record turn "is it allowed" into "is it allowed, and on which tier".

Education and duty of care

Schools face a sharper version of the same problem, layered on top of legal obligations. In the United States, districts that receive certain federal funding must operate a technology protection measure under the Children's Internet Protection Act; the Federal Communications Commission's CIPA guidance sets out the requirement. AI chatbots, essay generators and deepfake tools complicate that duty enormously: a district may want to permit an approved AI tutor that supports learning while blocking an essay-writing service that undermines academic integrity, or a companion-chat app inappropriate for minors. A single "AI" category cannot express that policy; per-subcategory classification can.

Academic-integrity offices are grappling with the same distinction. University teaching-and-learning centers, such as the guidance published by Stanford University and other institutions on generative AI in coursework, increasingly frame the question not as "AI or no AI" but as "which uses of which tools are appropriate for which assignments." Enforcing a nuanced policy at the network level requires data that is equally nuanced.

Why a purpose-built, refreshed feed

General web-categorization databases were not designed for this. They answer "is this a shopping site, a news site, a social network?", not "is this an AI code assistant, an AI voice cloner or an AI research agent?" The pace is also different: general categories are stable for years, whereas AI tools appear and disappear weekly. The dataset behind this client is rebuilt daily precisely so that new tools are caught close to launch rather than months later, and it is organized around the functional distinctions that policy actually turns on.

The public-interest research community has long argued that transparency and classification are prerequisites for governing new technologies. Digital-rights organizations such as the Electronic Frontier Foundation emphasize that filtering and monitoring must be precise and accountable rather than blunt, and precision is exactly what per-category domain intelligence enables. A well-classified feed lets an administrator write a rule that blocks a genuine risk category without collaterally breaking legitimate, sanctioned tools, which is the difference between a policy people follow and one they route around.

Where this package fits

This library is the bridge between that intelligence and your own systems. Drop lookup() into a proxy plugin or SOAR playbook for real-time decisions; run download_database() on a nightly cron to seed a DNS sinkhole or firewall EDL. Because the heavy matching runs locally against data you have already synced, the approach scales from a single script to millions of lookups a day without hammering the API. A second Python client positioned for enforcement points, with a feeds sub-client, a Lookup object with properties and a command line entry, is published as aiblocklist.

Discovery usually comes before policy. Most teams first want to find the AI tools employees use today: that hosted audit takes a DNS, proxy or firewall export and returns every AI tool reached from the network, who used it and whether the vendor trains on the data, as a dated CSV and PDF evidence pack, matched against the same list this client queries.

If AI-tool visibility and control are on your roadmap, for security, for compliance, or for duty of care, the AI Tools Blocklist lookup API provides the data, and this package provides the Python integration.

Enterprises that extend AI-tool governance beyond a single policy area usually need broader category coverage than an AI-only blocklist provides. Our internet filtering database supplies 120 million domains across 59 categories as a downloadable dataset that drops into the same firewalls, DNS resolvers and secure web gateways that consume this blocklist. Running both feeds side by side lets one policy engine enforce AI restrictions, acceptable-use rules and security blocking from a single source of domain intelligence.

Districts and libraries that already enforce AI-tool policies typically operate under the Children's Internet Protection Act, and our school web filtering solution provides the 120-million-domain classification backbone those CIPA programs depend on, with daily refreshes and multi-label categories that reduce over-blocking of legitimate educational content. Phishing remains one of the top attack vectors targeting school networks, and an anti-phishing threat feed with 390,000+ DNS-verified active phishing domains lets the same DNS resolver or firewall that blocks AI tools also block credential-harvesting pages in real time.

---

Frequently asked questions

What is the AI tools blocklist? The AI tools blocklist at aitoolsblocklist.com is a daily-refreshed database of 20,000+ AI-tool domains classified into 18 functional categories and their subcategories: chatbots and assistants, code assistants, image generators, video generators, voice cloning and speech, autonomous agents, AI companions, document and data tools, search and research tools and more. It is delivered as a lookup API and as ready-made feeds (EDL, PAC, hosts and DNS formats) for firewalls, DNS resolvers, secure web gateways and DLP systems.

How do I block ChatGPT, Gemini, Midjourney and other AI tools on a company or school network? Load the AI tools blocklist feed into the filter you already run: an External Dynamic List on a firewall, a PAC file for browsers, a hosts file or a DNS feed for resolvers. Then use the categories to allow the tools you sanction and block the rest. For real-time decisions in a proxy plugin or SOAR playbook, call the API with pip install aitoolsblocklist (Python) or npm install aitoolsblocklist (Node.js).

Can I allow some AI tools and block others? Yes. Every domain carries a primary category, a multi-label category list with subcategories, an AI type and the vendor's training terms, so a policy can permit an approved coding assistant or AI tutor while blocking deepfake, voice-cloning or companion-chat services. Paid plans also include 15 AI Policy Profiles with ready-made Block, Controls and Allow verdicts per sector.

Does the API say whether a vendor trains on my data? Yes. Each lookup returns trains_on_data, opt_out_available, enterprise_no_training, api_no_training and terms_checked, and clause() returns the verbatim sentence from the vendor's terms with its URL.

How is the AI tools blocklist different from the "AI" category in a web filtering product? General web filtering products classify sites by topic (shopping, news, social media) and usually offer one flat "generative AI" category that is updated on the vendor's schedule. The AI tools blocklist is a purpose-built feed: 18 categories with subcategories, AI types, training verdicts, and a daily rebuild so that tools are caught close to launch. It is extracted from a 120-million-domain web filtering infrastructure and is sold as data, so it works alongside any filtering product rather than replacing it.

How often is the AI tools blocklist updated? Daily. stats() shows the live totals without a key, and database_info() shows the timestamp of the file your plan can download, so a nightly cron keeps a local copy current.

Is the AI tools blocklist suitable for schools and CIPA compliance? Yes. Districts and libraries use it to block essay generators, deepfake tools and companion chatbots while allowing approved AI tutors, and it complements the general filtering database that CIPA programs rely on; see cipawebfiltering.com.

What formats does the AI tools blocklist ship in? Lookup API (JSON), External Dynamic List (plain domain list for firewalls), PAC file, hosts file and DNS feeds, plus CSV and JSON downloads of the full classified list with categories.

Who builds the AI tools blocklist? Alpha Quantum, the company behind the web filtering database, the website categorization API and the AI agent allow list, which covers the other direction of AI governance: what an organization's own AI agents may open on the web.

Links

• Product and API documentation: https://www.aitoolsblocklist.com
• NIST AI Risk Management Framework: https://www.nist.gov/itl/ai-risk-management-framework
• FCC, Children's Internet Protection Act: https://www.fcc.gov/consumer-governmental-affairs/childrens-internet-protection-act
• NVIDIA NeMo Guardrails (programmable rails for LLM applications): https://developer.nvidia.com/nemo-guardrails
• OWASP Top 10 for LLM Applications: https://owasp.org/www-project-top-10-for-large-language-model-applications/

License

MIT

Blocking unsanctioned AI tools addresses only half of the shadow-AI problem; the other half is what employees paste into the tools that remain allowed. A GDPR PII detection service can scan prompts, chat exports and DLP logs for personal data before it reaches an external model. Combining a daily-refreshed AI tool blocklist with automated PII removal gives compliance teams control over both which AI services are reachable and what data can flow into them.

Blocking risky AI tools governs what your people use; the complementary question is what your AI agents may touch on the web. An AI agent allow list supplies verified page-type URLs across 40 million+ domains, up to 28 page types each, so autonomous agents can research freely while credential and payment surfaces stay off-limits. Together, tool blocking and agent access policy data cover both directions of enterprise AI governance.

Related packages

• aiblocklist on PyPI and on npm, the enforcement-point client for the same API
• aitoolsblocklist on npm, the Node.js version of this package
• shadowaitools on PyPI and on npm, local log scanner for shadow AI tools
• aiagentallowlist on PyPI and on npm, client for the AI agent allow list
• phishingdetectionapi on PyPI and on npm, from phishingdetectionapi.com
• webfilteringdatabase on npm, from webfilteringdatabase.com
• websiteclassificationapi on PyPI and websitecategorization on npm, from websitecategorizationapi.com
• cipawebfiltering on PyPI and on npm, from cipawebfiltering.com
• PII detection API

Source: github.com/explainableaixai/aitoolsblocklist, mirror at gitlab.com/url-classifications/aitoolsblocklist.