canonical: https://jentic.com/apis/cybergordon.com/cybergordon # CyberGordon API Jentic publishes the only available OpenAPI specification for CyberGordon API, keeping it validated and agent-ready. CyberGordon is a cyber-reputation aggregator that submits an observable - an IP address, domain, URL, file hash, or email - to multiple security intelligence engines and returns a consolidated risk view. The five endpoints cover analysis submission, request status lookup, results retrieval, and the list of underlying engines. Result data, including suspicious and malicious indicators with links to the original sources, is retained for seven days. ## For AI agents Submit an IP, domain, URL, hash, or email to CyberGordon and receive an aggregated reputation report drawn from multiple threat intelligence engines. ## Scope Does not handle endpoint protection, vulnerability scanning, or active blocking - use for aggregated reputation lookups on individual observables only. ## Capabilities - Submit a single observable for analysis via GET `/request/{observable}` - Submit one or more observables via POST `/request/form` for bulk analysis - Look up request metadata to track which engines are still running via GET `/get-request/{requestId}/info` - Retrieve aggregated analysis results via GET `/get-request/{requestId}/results` - Inspect the live list of underlying intelligence engines via GET `/assets/json/engine_list.fddb0.json` - Surface suspicious and malicious flags with links to the original engine source for each finding ## Use cases ### Triage suspicious indicators in security workflows Send a suspect IP, domain, URL, hash, or email to CyberGordon and receive a consolidated reputation view drawn from engines like IPinfo, AbuseIPDB, VirusTotal, urlscan.io, GreyNoise, and Pulsedive. Analysts use the aggregated suspicious/malicious flags to triage indicators quickly without juggling several individual portals. Example prompt: Submit IP 1.2.3.4 via `/request/{observable}`, poll `/get-request/{requestId}/info` until complete, then return the aggregated malicious-flag count from /results. ### Phishing email investigation When a user reports a phishing email, an automated workflow extracts the sender email, sending IP, and any URLs in the body, and submits each as an observable. The aggregated report makes it clear whether multiple engines already flag the indicators, which lets the analyst close low-quality reports quickly. Example prompt: POST `/request/form` with the email's sender domain and the URL extracted from the body, then return malicious counts from the results endpoint. ### Bulk indicator enrichment for a SIEM Enrich a feed of indicators flowing into a SIEM with CyberGordon's consolidated reputation. A scheduled job batches new indicators, calls POST `/request/form`, and writes the aggregated risk score back to the SIEM event so detection rules can prioritise alerts that multiple engines flag. Example prompt: Submit 50 observables in one POST `/request/form` call and return the aggregated suspicious/malicious totals per indicator. ### AI agent threat lookup via Jentic Give an autonomous agent a tool to check whether a URL or IP is known-bad before acting on user input. The agent searches Jentic for 'check the reputation of a URL', loads the schema, polls the request, and returns the aggregated score. CyberGordon requires no authentication, but Jentic still standardises the discovery and execution path. Example prompt: Through Jentic, submit a URL extracted from chat input and surface a one-line summary of the aggregated CyberGordon results to the user. ## Key endpoints | Method | Path | Description | | --- | --- | --- | | GET | `/request/{observable}` | Submit a single observable for analysis | | POST | `/request/form` | Submit one or more observables in a single call | | GET | `/get-request/{requestId}/info` | Get request metadata and progress | | GET | `/get-request/{requestId}/results` | Retrieve aggregated analysis results | | GET | `/assets/json/engine_list.fddb0.json` | List the underlying threat intelligence engines | ## Key resources - **Analysis** — Submit observables (IP, domain, URL, hash, email) for reputation analysis - **Results** — Retrieve aggregated analysis results and per-engine findings - **Engines** — Inspect the live list of underlying threat intelligence engines ## Why Jentic - **Setup:** Wiring the CyberGordon API by hand means orchestrating its submit, poll, and fetch sequence for each observable and parsing the engine results yourself. Through Jentic you install once, import the CyberGordon API from the API Directory, and your agent calls it even though the API itself needs no credential. - **Permission scoping:** CyberGordon puts the observable and request id in the URL path (`/request/{observable}`, `/get-request/{requestId}/results`), so a rule can pin your agent to reading one request's results. You choose the operations it may call, so submitting new observables is not included unless you add it. - **Credential handling:** CyberGordon needs no credential, so none is stored, and Jentic still routes the call through your own Jentic One instance at execution time. Nothing sensitive enters the agent's prompt, logs, or context. - **Discovery method:** Agents search Jentic by intent such as 'check the reputation of a URL', and Jentic returns the matching CyberGordon submit and results operations with their input schemas so the agent runs the right sequence without browsing the reference docs. ## Related APIs - **AbuseIPDB** — Single-source IP-abuse reputation database - **Shodan** — Internet-exposed asset and banner intelligence - **Pulsedive** — Threat intelligence platform with indicator enrichment and feeds ## FAQ ### Why is there no official OpenAPI spec for CyberGordon? CyberGordon does not publish an OpenAPI specification on its docs site. Jentic generates and maintains this spec so that AI agents and developers can call CyberGordon via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer. ### What authentication does the CyberGordon API use? The spec defines no security scheme, so the API can be called anonymously, which is useful for read-only reputation lookups. Through Jentic, calls are still routed via the standard search/load/execute flow for consistent observability. ### What kinds of observables can CyberGordon analyse? IP addresses, domains, URLs, file hashes, and email addresses. Submit one observable via GET `/request/{observable}` or several at once via POST `/request/form`, then poll the request id for results. ### Which threat intelligence engines does CyberGordon aggregate? CyberGordon pulls from engines including IPinfo, AbuseIPDB, VirusTotal, urlscan.io, Google Safe Browsing, GreyNoise, and Pulsedive. The current live list is exposed via GET `/assets/json/engine_list.fddb0.json.` ### How long are CyberGordon results retained? Aggregated request results are retained for seven days. Persist any results you need long-term to your own storage, since `/get-request/{requestId}/results` will stop returning them after the retention window. ### How do I check a URL's reputation through Jentic? Run pip install jentic, search for 'check the reputation of a URL', load the request and results schemas, and execute. Jentic submits the observable, polls `/get-request/{requestId}/info`, and returns the aggregated results in one flow. ### Can I limit what my agent is allowed to do with the CyberGordon API? Yes. Jentic One is self-hosted, so your own rules decide which CyberGordon operations and credentials the agent may use. Because the observable and request id sit in the URL path (`/request/{observable}` and `/get-request/{requestId}/results`), you can pin the agent to reading a single request's results, and submitting new observables stays out of reach unless you explicitly add that operation.