Internal Security Product Integration
Connecting security devices and external systems to Flocks is usually the first step in enterprise deployment. Systems such as TDP / NDR / XDR / HIDS / EDR / honeypots / SIP / intelligence sources are deployed differently across enterprises, and integration methods vary.
This guide covers:
- When facing a device, how to choose an integration path such as API, log push, or browser.
- Under the API integration path, how to generate and validate reusable tools from API documentation.
Scenario Overview
Flocks already includes a set of integration examples for mainstream security devices / intelligence sources:
- Intelligence: ThreatBook TIP, VirusTotal, GreyNoise, FOFA
- Traffic / alerts: ThreatBook TDP, OneSEC, QiAnXin SkyEye
- Endpoint: Qingteng Cloud HIDS
Real enterprise environments often contain systems that are not preset. Therefore, the key to this scenario is not the number of built-in devices, but whether reusable tools can be quickly generated, validated, and captured based on API documentation. This is the foundation for Flocks moving from an advisory assistant to an execution platform.
Integration Method Priority
When encountering a new device, choose an integration method in this order:
| Priority | Method | Suitable for | Not suitable for |
|---|---|---|---|
| ★★★ | Official / private API | Long-term stable operation, scheduled tasks, batch calls | No API is exposed |
| ★★☆ | Log push / message queue / relay script | Device itself is an event source and standardization is desired | Real-time query response is required |
| ★☆☆ | Web Scraping / Browser Automation post-login | No API, data only available from Web console | Long-term operation as the main path |
Core conclusion: the browser approach is a fallback path and should not be the long-term main path. API is more stable, has lower maintenance cost, and is more suitable for scheduled tasks. For browser usage, see Browser Automation and Web Login.
Does the Internal Environment Need Internet Access?
Flocks itself does not require public internet access. Whether public internet is needed mainly depends on the selected model and external services:
| Model choice | Public internet required |
|---|---|
| Private / locally deployed model | No |
| Internal model service | No, as long as the model service is reachable |
| External cloud model, such as OpenAI or Claude | Yes |
Therefore, whether Flocks can be deployed internally mainly depends on whether the model service and external dependencies are reachable, not Flocks itself.
API Integration Main Path (Recommended)
This is an integration capability that Flocks is well suited to highlight: when a device or platform provides API documentation, authentication methods, and typical request examples, Rex can help generate tools, validate the call chain, and add them to the platform's unified tool system.
Steps (WebUI)
Enter Session Management -> + New Session
Describe the goal in natural language, for example:
"Help me search the web for VT API documentation, then integrate the VT API service. The Key is in the file I just sent."
Rex will:
- Use Web Search to obtain API documentation; skip this step if documentation has already been provided
- Generate a Python / API tool based on the documentation
- Fill in the Key
- Automatically run a validation call
- If validation fails, adjust the implementation based on the error and validate again
The tool is written to Tools, and Rex can call it directly afterwards
Optional: record conventions / rate limits / field mappings for this type of device in a Skill for long-term capture
Real Case Walkthrough: VT API Integration
Key points from a VT API integration demo:
| Time | Rex action | Notes |
|---|---|---|
| 0:02 | Assume an API document already exists | The demo first deletes the existing VT tool to show re-integration |
| 0:38 | User requests VT API integration in natural language | Rex plans the integration steps based on the goal |
| 1:05 | Rex starts Web Search | Around one to two minutes |
| 1:33 | Tool is created | Creation does not mean the call chain is usable yet |
| 1:48 | Rex continues validating whether the Key can call normally | Critical step |
| 2:03 | Validation passes and tool storage completes | VT tool returns to the Tools list |
| 2:26 | Summary | Completes the loop from requirement input to tool creation, validation, and debugging |
Value of This Path
- Integration speed: interface wrapper work that previously required development can be significantly shortened
- Reusable capture: generated tools directly enter the Tools directory and can be used by all later sessions
- Error correction: after failure, Rex can continue debugging based on error information instead of stopping at the first failure
- Iterative: to change fields or add parameters, continue in the conversation
MCP Integration
In addition to API tools, Flocks supports unified integration through MCP (Model Context Protocol):
- MCP server already provided by a third party -> configure it and add it to the tool system
- Enterprise-built MCP server -> integrate through the unified protocol
- Benefit of MCP: consistent protocol and reuse across AI platforms
API tool or MCP? A simple rule:
- This capability is only for Flocks -> API tool is sufficient
- This capability may be reused across multiple AI platforms -> use MCP
Log / Message Queue Integration (Second Priority)
Some devices are naturally event sources, such as syslog, kafka, or message buses. Organize these scenarios as follows:
- Devices push logs / events to the enterprise aggregation layer in the existing way, such as syslog server, kafka cluster, or ES
- Write a lightweight API tool or MCP server to fetch data from the aggregation layer, instead of connecting directly to the device
- Rex calls this tool to obtain structured events and continue analysis
Benefits:
- No device-side changes
- The aggregation layer naturally performs standardization
- Flocks requires no changes during updates / scaling
Browser Approach (Fallback, Not Recommended as Main Path)
Only consider letting Rex call the browser tool to log into the Web console and fetch data when neither API nor logs are available. For usage and boundaries, see Browser Automation and Web Login.
One point is worth emphasizing: backend interfaces discovered through the browser can be converted into stable API tools. During Web operations, Rex observes actual XHR / Fetch requests sent by the browser. When needed, it can capture those request patterns as Python / CLI tools. This is the Flocks closed-loop idea of "browser access -> tool capture."
Prerequisites
| Dependency | Requirement |
|---|---|
| Model | Stronger reasoning capability improves API auto-debugging success rate |
| Network | The node running Flocks can reach the target device API / Web / log aggregation layer |
| Credentials | Device API Key / Token / account password, recommended to manage through Workspace secrets |
| Web Search tool | Required if Rex must automatically search for API documentation; not required when documentation is directly provided |
Continuous Operation Recommendations
- After integration completes, have Rex run one validation call, not just check whether the tool appears in the list
- Capture "constraints when calling this device" such as rate limits, required headers, and field mappings as a Skill
- Attach recurring data pulls to Task Center for scheduled execution
- Connect failure alerts to channels such as DingTalk / WeCom so operations can monitor integration stability
Boundaries and FAQ
| Question | Handling |
|---|---|
| Device API documentation is Word / PPT / scanned | Convert it to text first, such as with pdftotext / OCR, then provide it to Rex |
| The documentation has many APIs, but only a few are needed | Tell Rex "only integrate /v1/ioc and /v1/sample" |
| 401 appears after integration runs for a while | Usually the Token expired; refresh the Key in Tools |
| Want the integrated tool to be dedicated to a specific expert Agent | Explicitly declare it in the Agent definition under tools:, instead of exposing it globally |
| Fields do not match business needs after integration | Ask Rex to "add a conversion layer" and generate a wrapper tool |
| API is rate-limited | Write rate-limit rules in a Skill so Rex respects them, or use the log layer to avoid direct calls |
Related Resources: Scenario Overview · Browser Automation and Web Login · Alert Triage · Threat Intelligence and IOC Triage · Tool List · MCP Integration