API and integrations

Connect security tools without fragmenting operations

Understand how AegiFlow receives portable detections, scanner results, threat intelligence and SOC evidence while keeping one customer workflow.

What this integration layer does

AegiFlow is the operating and evidence layer for the protected web service. It can receive detections, inventories or investigation results from specialized tools, but customers continue to work in one flow:

evidence -> affected service -> protection status -> case
-> proposed action -> verification -> recovery evidence

An integration cannot block traffic, change DNS or isolate an origin directly. Those actions still require the service Safety Contract, an AegiFlow policy decision, a time limit, verification and rollback.

Supported integration patterns

• Sigma rules as portable detection content with source, version and data requirements.
• STIX/TAXII or MISP records as threat intelligence with provenance and expiry.
• Wazuh, Suricata, Zeek or a SIEM as customer-operated event sources.
• TheHive or a partner SOC as case handoff destinations.
• Nuclei, Trivy, Amass and similar tools as future bounded, explicitly authorized one-shot jobs.

AegiFlow does not require these products for ordinary web protection and does not install all of them on the customer traffic node.

Configure an integration

1. Open Settings → Integrations and select the organization and service.
2. Choose the evidence type and the minimum required scope.
3. Create a credential dedicated to that producer.
4. Configure signature, timestamp and nonce handling.
5. Send a test record that contains no personal data or secret.
6. Confirm service mapping, provenance, freshness and the resulting case state.
7. Enable production ingestion with an explicit quota.

How to verify it

Open the resulting evidence record. It must show the source, producer, service, received time, event time, data classification and matching confidence. Incomplete enrichment must display Unknown, not Clear.

Disable the producer and replay the same nonce. The request must be rejected, while the already accepted evidence remains available for audit.

Operational limits

Active scanning, endpoint collection and adversary emulation require separate written authorization and an allowlisted scope. They run outside the visitor request path with CPU, memory, request, duration and egress limits.

Read the current architecture decision in the public product documentation before enabling a new integration type.

Verification

• Imported records show source and freshness
• Unknown evidence remains unknown
• No integration can bypass the response approval flow