Adds note about unsupported agentless streams to Zscaler ZIA integration

[jmikell821]

Proposed commit message

Adds note about unsupported agentless streams to Zscaler ZIA integration

Checklist

• I have reviewed tips for building integrations and this pull request is aligned with them.
• I have verified that all data streams collect metrics or logs.
• I have added an entry to my package's changelog.yml file.
• I have verified that Kibana version constraints are current according to guidelines.
• I have verified that any added dashboard complies with Kibana's Dashboard good practices

Author's Checklist

• Check for content accuracy.

Related issues

Resolves elastic/docs-content#4169.

[github-actions]

Please run these commands to update changelogs and build docs:

for pkg in zscaler_zia; do
  cd packages/$pkg
  elastic-package changelog add --type enhancement --description "Improve documentation" --link "https://github.com/elastic/integrations/pull/19106" --next minor
  elastic-package build
  cd ../..
done
git add -u
git commit -m "docs: update changelogs and build documentation"
git push

Prerequisite: go install github.com/elastic/elastic-package

[github-actions]

✅ Vale Linting Results

No issues found on modified lines!

---

The Vale linter checks documentation changes against the Elastic Docs style guide.

To use Vale locally or report issues, refer to Elastic style guide for Vale.

[github-actions]

⚠️ Package docs validation failed. Please check the workflow run for details.

For support, reach out in the #docs Slack channel.

cc @elastic/integration-docs

[github-actions]

TL;DR

The Buildkite failure is caused by a README sync check failure: packages/zscaler_zia/_dev/build/docs/README.md was edited, but the generated packages/zscaler_zia/docs/README.md was not in sync for commit 5d42ece92251a419ffc4e12c0e4b6790d953fa7c. Regenerate docs for zscaler_zia and include the generated README in the commit.

Remediation

• Run elastic-package build from packages/zscaler_zia/ (or your usual package build command) after editing _dev/build/docs/README.md.
• Commit the regenerated packages/zscaler_zia/docs/README.md so lint/readme-up-to-date checks pass.

Investigation details

Root Cause

This is a configuration/docs generation failure (not an infra/transient issue): the package check enforces that README artifacts are up to date.

• The failing commit (5d42ece...) only modified:
  • packages/zscaler_zia/_dev/build/docs/README.md
• It did not include the generated packages/zscaler_zia/docs/README.md update expected by the check.

The check output shows a direct content mismatch and exits non-zero.

Evidence

• Build: https://buildkite.com/elastic/integrations/builds/43185
• Job/step: Check integrations zscaler_zia (.buildkite/scripts/test_one_package.sh packages/zscaler_zia origin/main 5d42ece...)
• Key log excerpt:

README.md is outdated. Rebuild the package with 'elastic-package build'
...
Error: checking package failed: checking readme files are up-to-date failed: files do not match

• Diff excerpt from failing log (generated vs committed):
  • New agentless docs URLs and note block are present in generated output but absent in committed README at that commit.

Verification

• Not run locally in this workflow; analysis is based on Buildkite failure logs and PR/commit metadata.

Follow-up

If you already pushed a follow-up commit that includes regenerated docs, this specific failure should be resolved on the next CI run for the new commit SHA.

Note

🔒 Integrity filter blocked 10 items

The following items were blocked because they don't meet the GitHub integrity level.

• 8ea0eae list_commits: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• 5d42ece list_commits: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• 6f3b899 list_commits: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• cf9bd94 list_commits: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• 6512613 list_commits: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• 2da78e5 list_commits: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• 01d7a31 list_commits: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• 57cd260 list_commits: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• 1be709b list_commits: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• 8fe1265 list_commits: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".

To allow these resources, lower min-integrity in your GitHub frontmatter:

tools:
  github:
    min-integrity: approved  # merged | approved | unapproved | none

---

What is this? | From workflow: PR Buildkite Detective

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.

[jmikell821]

Hi @renangenova, can you review the text in this file please and ensure the content is accurate? packages/zscaler_zia/_dev/build/docs/README.md. I will bring up the issue of the whole integration being marked as agentless with our Ingest docs and Engineering teams. Maybe we could have two policy templates instead of one that marks it wholly as agentless: enabled: true.

policy_templates:
  - name: zscaler_zia
    deployment_modes:
      default:
        enabled: true
      agentless:
        enabled: true

[elastic-vault-github-plugin-prod]

🚀 Benchmarks report

To see the full report comment with /test benchmark fullreport

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: 8ea0eae

History

• 💔 Build #43185 failed 5d42ece

cc @jmikell821

[kcreddy]

@jmikell821,
This pattern applies to at least 20 other agentless-enabled integrations that have data streams using agentless-disabled inputs (tcp, http_endpoint, azure-eventhub, aws-s3, gcp-pubsub, logfile, streaming, etc.). Some examples:

• crowdstrike: falcon (logfile, streaming) and fdr (aws-s3) can't run agentless, while alert/host/vulnerability (cel) can
• m365_defender: event (azure-eventhub) can't, while alert/incident (httpjson) and vulnerability (cel) can
• wiz: defend (http_endpoint) can't, while audit/issue/vulnerability (cel) can
• prisma_cloud: host/host_profile/incident_audit (tcp, udp) can't, while alert/audit/vulnerability (cel) can
• o365: audit via o365audit can't, while audit via cel can

Fleet already hides ineligible data streams when agentless is selected, so users won't accidentally configure something that doesn't work. The gap is in the integration docs and catalog listing — users see "agentless-enabled" and may assume full coverage before they get to the Fleet UI.

Is this documentation note intended to be applied to all ~21 affected packages, or just zscaler_zia for now?

[infra-vault-gh-plugin-prod]

Pinging @elastic/security-service-integrations (Team:Security-Service Integrations)

[jmikell821]

Hi @kcreddy, I'll just merge this one for Zscaler for now, and I'll open a new issue and track the work for the other ones separately. I think we need to consider a long-term solution that may involve updating the automation.

@jmikell821, This pattern applies to at least 20 other agentless-enabled integrations that have data streams using agentless-disabled inputs (tcp, http_endpoint, azure-eventhub, aws-s3, gcp-pubsub, logfile, streaming, etc.). Some examples:

• crowdstrike: falcon (logfile, streaming) and fdr (aws-s3) can't run agentless, while alert/host/vulnerability (cel) can
• m365_defender: event (azure-eventhub) can't, while alert/incident (httpjson) and vulnerability (cel) can
• wiz: defend (http_endpoint) can't, while audit/issue/vulnerability (cel) can
• prisma_cloud: host/host_profile/incident_audit (tcp, udp) can't, while alert/audit/vulnerability (cel) can
• o365: audit via o365audit can't, while audit via cel can

Fleet already hides ineligible data streams when agentless is selected, so users won't accidentally configure something that doesn't work. The gap is in the integration docs and catalog listing — users see "agentless-enabled" and may assume full coverage before they get to the Fleet UI.

Is this documentation note intended to be applied to all ~21 affected packages, or just zscaler_zia for now?

[renangenova]

Hi @renangenova, can you review the text in this file please and ensure the content is accurate? packages/zscaler_zia/_dev/build/docs/README.md. I will bring up the issue of the whole integration being marked as agentless with our Ingest docs and Engineering teams. Maybe we could have two policy templates instead of one that marks it wholly as agentless: enabled: true.

Hiya! The readme change below LGTM:

NOTE: When using an agentless deployment, only the Sandbox Report data stream is available. Sandbox Report uses the API-based CEL input, which is compatible with agentless mode. Other data streams (Alerts, Audit, DNS, Endpoint DLP, Firewall, Tunnel, Web) require TCP or HTTP Endpoint inputs, which are not supported in agentless deployments. To collect data from these data streams, use Elastic Agent.

[elastic-vault-github-plugin-prod]

Package zscaler_zia - 3.18.0 containing this change is available at https://epr.elastic.co/package/zscaler_zia/3.18.0/