DorkAgent: an LLM agent that picks Google dorks for you
🤖 LLM-powered agent for automated Google Dorking in bug hunting & pentesting.
At a glance
- What is it?
- DorkAgent wraps Serper or SerpApi search behind a CrewAI agent, generates dorks from a target domain, and writes a findings report. It is a convenience layer over two paid APIs, not a scanner, and the README assumes you can edit files inside site-packages.
- Who is it for?
- Adopt DorkAgent if you already pay for Serper or SerpApi and want the dork selection and report writing handled by a model instead of by hand. Skip it if you need reproducible, auditable query sets, if you cannot edit files under site-packages, or if your target's scope rules forbid third-party search APIs.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 23 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What DorkAgent actually automates
Google dorking for bug bounty work is a loop: write a query, read results, write a better query. DorkAgent's README frames the project as an LLM-powered agent for that loop, aimed at bug hunters and pentesters who already know what a dork is and want the query-writing step delegated. The repository ships a curated dork set, and the README points at TakSec's google-dorks-bug-bounty list as the reference for the dorks in task(). That reference matters: the agent is not inventing syntax, it is selecting and sequencing from a known corpus with a model in the loop. The target audience is narrow. You need a search API key, at least one LLM API key, and a tolerance for a tool whose behaviour changes when the model changes. Someone who wants a static dork list to paste into a browser gains nothing here. Someone running recon across many scoped domains, where the per-target query writing is the tedious part, is the intended user.
How the CrewAI layer turns a domain into a report
The project is a CrewAI crew. The 2025-09-29 refactor split a file that the changelog describes as over 800 lines into config.py, agents.py, tasks.py and utils.py, with dorkagent.py as the entry point. Agents are defined in agents() and work is defined in task(), both of which the README tells you to edit directly. Search is delegated to CrewAI's own tools: SerperDevTool for Serper and a SerpApi tool, both living inside crewai_tools in site-packages. That placement is the architectural fact that matters most. The search integration is not vendored into DorkAgent; it is consumed from the installed crewai_tools package, so the tool's defaults and its omissions are inherited. The SerpApi tool, per the README, forwards only q and location by default, which means result count and time filtering are not exposed unless you patch the tool. The 2026-08-24 entry notes that OpenAI access moved to CrewAI's native LLM wrapper because ChatOpenAI was no longer accepted by Agent, and that crewai[anthropic] and crewai[google-genai] extras are now required for the other providers. Reports are written to files with timestamps in YYMMDD_HHMMSS format, a change from the 2025-09-29 refactor.
Setup: one script, three prompts, four key names
The documented install is two commands: git clone https://github.com/yee-yore/DorkAgent.git, then cd DorkAgent, then python dorkagent.py. There is no pip install step in the README because the script auto-installs its dependencies on first run. On that first run it prompts for a search engine (Serper or SerpApi), prompts for an LLM provider, and prompts for the corresponding API keys, writing them to a .env file. The key names are SERPER_API_KEY, SERPAPI_API_KEY, OPENAI_API_KEY, ANTHROPIC_API_KEY and GEMINI_API_KEY. You need exactly one search key and at least one LLM key. The Python version constraint is stated plainly: 3.11.x, recommended 3.11.9. The README explains why, and the explanation is specific enough to trust. Newer interpreters such as 3.13 may fail to install crewai dependencies like tiktoken because no prebuilt wheel exists for them, so pip falls back to a source build that needs a Rust compiler. If that build fails, the documented remedy is to move to 3.11.x. The 2026-08-24 entry also mentions a retry-on-invalid-API-key flow replacing an exit, which matters if you mistype a key during the prompt sequence.
Customisation means editing site-packages
This is where the design gets uncomfortable. To change how many Google results come back on Serper, the README directs you to serper_dev_tool.py inside site-packages/crewai_tools/tools/serper_dev_tool/ and to change n_results, documented as minimum 10 and maximum 100. To filter by recency on Serper, you edit the payload in _make_api_request to add or change the tbs key, with qdr:w for the past week and qdr:m for the past month. For SerpApi, the same two controls require adding num and tbs keys to the client.search({...}) dict in _run() inside serpapi_google_search_tool.py. Nothing in the README describes a config file, environment variable or CLI flag for result count or time window. Those edits live in an installed third-party package, so they are lost on a crewai_tools upgrade and are not captured by cloning the repository. The .env file the script writes is the only project-local configuration surface, and it holds keys, not search parameters. If you deploy this anywhere beyond a workstation, that is the first thing you will have to solve, and the README does not solve it for you.
Where the agent model becomes a liability
The dork set is fixed and referenced from an external bug bounty list, but selection and sequencing are model-driven, and the changelog shows that behaviour shifting with prompts. The 2025-04-17 entry removed a dork for finding Confidential documents because most results were merely informative, and removed dorks targeting login panels. Those are prompt and corpus edits, not code fixes, and they change what a run returns. Two runs on the same domain with different LLM providers, or the same provider at a different temperature, are not guaranteed to produce the same query set. For bug bounty work that is often acceptable, since the report is a lead generator rather than evidence. For any workflow that needs an auditable record of exactly which queries hit a third-party API on a given date, it is not. There is also a cost and rate dimension the README acknowledges only indirectly: the 2025-04-17 entry mentions added settings to help avoid LLM provider rate limits, and the 2026-08-24 entry mentions adding passive-OSINT context to the searcher task so the agent does not refuse recon on large or well-known domains. That second note is a real signal. The agent's willingness to proceed depends on prompt framing, which means a model with stricter refusal behaviour can stall a legitimate scoped engagement.
What you give up compared with running dorks by hand
The obvious alternative is not another agent. It is a shell script that reads a dork list and calls the Serper or SerpApi endpoint directly, or a tool like theHarvester for the subdomain and email collection parts of OSINT. The difference is in what the model contributes. A script sends every dork in the list, every time, and you can diff two runs character by character. DorkAgent sends what the agent decides to send, then writes prose about what it found. You trade determinism for the model's judgement about which dorks suit the target, and you gain a written report in exchange for the raw result set. The 2026-08-24 note about passive-OSINT context is exactly the kind of thing a script never needs, because a script does not refuse. If your engagement requires you to reproduce a finding from the query log, the script wins. If your bottleneck is reading hundreds of dork outputs and deciding which three matter, the agent is doing the part you did not want to do. Neither is strictly better, and the README does not pretend otherwise.
Maintenance, licence and the upgrade path
The project is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a statement about the licence text, not legal advice; if you are embedding this in a client deliverable, read the licence yourself. The maintenance surface is larger than the repository suggests. DorkAgent depends on crewai and crewai_tools, and the 2026-08-24 entry is a compatibility fix for crewai 1.15.17, so the project tracks upstream breaking changes rather than pinning against them. It also depends on the Serper and SerpApi APIs, whose pricing, quotas and response shapes are outside the project's control, and on whichever LLM provider you select, where model deprecations are routine. There are no releases in the material provided, so there is no versioned artifact to pin. Your upgrade path is git pull plus whatever the latest changelog entry says broke. Budget for that: every crewai_tools upgrade can silently revert the n_results and tbs edits you made in site-packages, and the symptom is not an error, it is fewer results or a wider time window than you intended.
Editorial conclusion
Adopt DorkAgent if you already pay for Serper or SerpApi and want the dork selection and report writing handled by a model instead of by hand. Skip it if you need reproducible, auditable query sets, if you cannot edit files under site-packages, or if your target's scope rules forbid third-party search APIs. Before trusting a run, check which engine you selected, confirm the n_results and tbs values actually reached the API payload, and read the generated report against the raw dork list to see what the model dropped.
Community notes