Repository navigation
Agentless Security Integrations Release - Phase II #14186
Description
Description
Building on the completion of Phase I (#11810), this Epic describes enabling agentless deployment for the next wave of security integrations. Phase I delivered 15+ integrations including Office 365, Okta, AWS Security Hub and others.
Phase II expands agentless support to additional high-priority security integrations based on customer demand/usage.
Security integrations targeted for Phase II release:
| Integration | Input | Owner | Agentless |
|---|---|---|---|
| ti_anomali | cel | @elastic/security-service-integrations | ✅ |
| ti_crowdstrike | cel | @elastic/security-service-integrations | ✅ |
| carbon_black_cloud | cel, httpjson | @elastic/security-service-integrations | ✅ |
| proofpoint_tap | httpjson | @elastic/security-service-integrations | ✅ |
| mimecast | cel, httpjson | @elastic/security-service-integrations | ✅ |
| checkpoint_harmony_endpoint | cel | @elastic/security-service-integrations | |
| checkpoint_email | cel | @elastic/security-service-integrations | ✅ |
| cisco_duo | cel, httpjson | @elastic/security-service-integrations | ✅ |
| trend_micro_vision_one | httpjson | @elastic/security-service-integrations | |
| guardduty | httpjson | @elastic/security-service-integrations | ✅ |
| inspector | httpjson | @elastic/security-service-integrations | ✅ |
| cloudflare | httpjson | @elastic/security-service-integrations | |
| imperva_cloud_waf | cel | @elastic/security-service-integrations | |
| auth0 | cel | @elastic/security-service-integrations | |
| 1password | httpjson | @elastic/security-service-integrations | ✅ |
| github | httpjson | @elastic/security-service-integrations | |
| slack | httpjson | @elastic/security-service-integrations | |
| ti_rapid7_threat_command | httpjson | @elastic/security-service-integrations | |
| tenable_sc | httpjson | @elastic/security-service-integrations | ✅ |
| snyk | cel, httpjson | @elastic/security-service-integrations | ✅ |
| abnormal_security | cel | @elastic/security-service-integrations | |
| digital_guardian | cel | @elastic/security-service-integrations | |
| ti_recordedfuture | httpjson | @elastic/security-service-integrations | ✅ |
| ping_one | httpjson | @elastic/security-service-integrations |
edit: Table statuses updated 2026-02-19
Requirements
Following the established Phase I pattern, for each integration see the Onboarding Integration Guide.
1. Technical implementation
- Update integration manifest.yml to enable agentless deployment mode ()
- Update integration documentation with agentless deployment instructions
- Update changelog.md
Example reference: #13367
2. Performance documentation
- Test and document throughput in agentless (requires access to vendor environment and/or sample data)
- Document specific metrics for each integration. For example/where possible:
- API response time: Average time for vendor API calls to complete
- Events processed per minute: How many log entries/events the integration can handle
- Error rates: Percentage of failed API calls or data processing errors
- Container resource usage: CPU and memory consumption under typical load
- Vendor-specific limits: Rate limiting thresholds and API quotas
Example documentation format: "Crowdstrike Falcon Intelligence: 200ms avg API response, 5,000 events/min, 0.1% error rate, 512MB RAM/0.5CPU, 1000 API calls/hour limit"
Dependencies
- Agentless infrastructure GA readiness (still in beta)
- Input compatibility: Currently agentless is optimized for httpjson and cel inputs
- UX enhancement: Add agentless deployment filter/toggle to integrations catalog page for better discoverability
References
Reacted by nima
Metadata
Metadata
Assignees
Labels
1PasswordAbnormal AIAuth0AWSVMware Carbon Black CloudCheck Point Harmony Email & CollaborationCheck Point Harmony EndpointCisco DuoCloudflareDigital GuardianGitHubImperva Cloud WAFMimecastPingOneProofpoint TAPSlack LogsSnykTenable Security CenterAnomali ThreatStreamCrowdStrike Falcon IntelligenceRapid7 Threat Command (Partner supported)Recorded FutureTrendAI Vision OneIssue or pull request for creating a new integration package.Crest developers on the Security Integrations team [elastic/sit-crest-contractors]Security Service Integrations team [elastic/security-service-integrations]New feature or request
Activity
cpascale43 commentedon Jun 9, 2025
cc @nimarezainia, if you'd like to weigh in on any required testing/benchmarking data.
nimarezainia commentedon Jun 10, 2025
@cpascale43 LGTM. At some point we should discuss timelines. As discussed since all of these are using CEL and HTTPJSON, there shouldn.t be much of an issue from the platform perspective. Benchmarking data would be fantastic.
kcreddy commentedon Jun 18, 2025
Related to
organizationfield pipeline errors inside Agentless integrations: #14142, a temporary fix similar to #14172 should be part of this implementation until elastic/kibana#221312 is closed.narph commentedon Aug 19, 2025
@kpollich , @ebeahan are there any concerns, limitations we need to consider before onboarding these integrations?
Do we need to increase memory size similar to #13760?
kpollich commentedon Aug 19, 2025
We haven't done a broad benchmark here on memory footprint, so it's hard to know the right answer for this right now. That being said, we could likely avoid a whole class of issues by just broadly upping the default memory for all agentless containers. This will incur costs.
@nimarezainia @ebeahan WDYT?
49 remaining items
andrewkroh commentedon Apr 22, 2026
I'd like to push back on the blanket 4Gi bump for all
ti_*integrations and propose we ship them at the default memory limit instead, paired with proactive monitoring.The 4Gi decision wasn't data-driven, and now the Agent itself is using less memory due to OTel related changes and we have some data from the already agentless-enabled TI integrations.
The thread itself acknowledges the sizing wasn't grounded in measurement:
Looking at the memory distribution over the last 24 hours across currently-deployed agentless TI integrations (data from the internal agentless overview dashboard):
Across every observed TI deployment, none exceeded 1 GB*. The heaviest bucket hit is 0.5–1.0 GB (ti_abusech). A 4 GB floor would over-provision these integrations by a large multiple.
*The one caveat isti_recordedfuture. We know this one has problems and there are some OOM kills with it. This is already planned to be addressed by implementing a native Go input that can stream-process the large CSV responses (100+ MiB). This is tracked in an internal issue.Proposal:
ti_*class pre-emptively.This helps keeps COGS predictable and avoids over-provisioning.
nimarezainia commentedon Apr 23, 2026
if we see that a particular ti_* integration is always having to be upgraded to a higher memory usage we can change the memory requirement for that specific ti_ package in its manifest.
@nkvoll and @kpollich these integrations could be a good candidate for one of the architectural options being discussed.
mohitjha-elastic commentedon Jun 4, 2026
We have completed the agentless enablement for all integrations listed above. Validation was performed using the mock server for integrations where instance details were unavailable.
As the agentless enablement has been completed, instance details are no longer required - #14341
kcreddy commentedon Jun 4, 2026
All the integrations in this Phase 2 list are now agentless enabled.
Moving the sub-issue #14341 (procuring licenses) as out-of-this-scope and closing this parent ticket. It can be tracked separately.
The next batch of agentless support for integrations is being tracked in: #17973
cc: @jamiehynds