Add PCI compliance skill and tools for Agent Builder

[smriti0321]

Update: This branch supersedes the earlier “PCI Compliance Agent + three tools” description. The shipped design is a PCI compliance skill and four tools (including field mapper), with no dedicated PCI BuiltInAgentDefinition.

Summary

This PR adds PCI DSS v4.0.1 support to Security Solution Agent Builder using the skills model instead of a standalone built-in agent.

• Introduces a pci-compliance skill (defineSkillType) with guided instructions for assessments, reporting, confidence interpretation, deduplication, and time-range behavior.
• Registers four PCI-specific tools: scope discovery, compliance checks, compliance reporting, and field mapping for non-ECS / custom sources.
• Wires the skill to platform Agent Builder tools (search, indices, mappings, documents, cases, product docs, generateEsql / executeEsql) plus security alerts and entity risk tools where relevant.
• Does not add a separate “PCI Compliance Agent” BuiltInAgentDefinition; users enable PCI workflows via the skill (aligned with Agent Builder’s skill-first direction).

Architecture

• Skill registration: register_skills.ts registers pciComplianceSkill.
• Tool registration: register_tools.ts registers PCI tools alongside existing security tools.
• Agents: registerAgents is unchanged for PCI (only the existing threat hunting agent is registered as a built-in agent).

Skill id: pci-compliance.
Skill content and tool allow-list live under:

• x-pack/solutions/security/plugins/security_solution/server/agent_builder/skills/pci_compliance/

PCI tool implementations:

• tools/pci_scope_discovery_tool.ts — PCI-relevant data coverage across indices
• tools/pci_compliance_check_tool.ts — requirement-level checks, violations, confidence
• tools/pci_compliance_report_tool.ts — structured / visual-style compliance reporting
• tools/pci_field_mapper_tool.ts — suggest ECS mappings for custom fields when ECS coverage is low

Shared requirement / query definitions:

• tools/pci_compliance_requirements.ts (and related modules as present in this branch)

Supporting wiring (allow-lists, constants, plugin registration) is updated so the new skill and tool IDs are permitted where required.

Relation to the previous PR revision

An earlier revision of this PR proposed a dedicated PCI Compliance Agent (BuiltInAgentDefinition). That approach was replaced by this skill + tools design so PCI is available as a composable skill without adding another first-class agent.

Test plan

• node scripts/check_changes.ts
• Jest — PCI tools and skill (e.g. pci_compliance_skill.test.ts, pci_*_tool.test.ts, including pci_field_mapper_tool.test.ts if applicable)

(Add any Elastic CI checkbox steps your team uses for this PR.)

Notes for reviewers

• Assessments are bounded by data quality, ECS alignment, index selection, and time windows; the skill text documents interpretation (e.g. GREEN/AMBER/RED, NOT_ASSESSABLE, deduplication).
• This matches the product expectation that “compliance” here is evidence-oriented telemetry and checks over customer data, not a substitute for a full manual PCI audit.

[cla-checker-service]

💚 CLA has been signed

[elasticmachine]

💔 Build Failed

• Buildkite Build
• Commit: ba1f6a9

Failed CI Steps

• Check Types
• FTR Configs #104
• Entity Analytics - Security Solution Cypress Tests #1

Test Failures

• [job] [logs] Entity Analytics - Security Solution Cypress Tests #1 / Entity Analytics Watchlists Management Page shows table when watchlists are returned shows table when watchlists are returned
• [job] [logs] FTR Configs #104 / Serverless Common UI - Management Data View Management creating and deleting default data view index pattern deletion "before all" hook for "should return to index pattern list"

Metrics [docs]

✅ unchanged

History

• 💔 Build #404622 failed 454056f

cc @smriti0321

[JordanSh]

Currently, these queries do not "prove" compliance. Instead, they act as telemetry health checks to prove that you are collecting data which potentially can be necessary to be audited. For example, I've asked the agent to show me the queries it runs together with the PCI Compliance result:

The query it used here just checks that we have event.category == "network" logs, which leads to a false green scenario. If the answer is Yes (matching_events > 0), you have only proven that your logging pipeline is working. This satisfies parts of Requirement 10 (Audit Trails), but it says nothing about the security state of the network.

Furthermore, it did not check an actual PCI requirement like shown in the examples in the PR description which requires much more specific queries:

PCI DSS Req 8.3.6 — Account Lockout After Failed Attempts.
What it checks: PCI DSS requires accounts to be locked after no more than 10 failed login attempts. 
This query finds accounts with more than 6 failed logins (industry best practice threshold), 
indicating that lockout mechanisms may not be enforced.

To that point, there are about 300 requirements in PCI DSS v4.0. If we are going to build an agent that claims to check compliance, we need to shift the implementation from Data Presence to Data Evaluation.

1. Proposed Queries

To provide actual auditor value, we must pivot to queries that look for violations. Below are the recommended ES|QL patterns that we should be using instead. I’ve asked an LLM to create more detailed queries just to see what that looks like:

1.1 Requirement 4: Weak Encryption in Transit

Goal: Identify legacy/weak protocols (SSL/early TLS).

buildEsql: (indexPattern, from, to) => `
  FROM ${indexPattern}
  | WHERE @timestamp >= "${from}" AND @timestamp <= "${to}"
  | WHERE network.protocol == "https" OR tls.version IS NOT NULL
  | WHERE tls.version IN ("1.0", "1.1") OR network.protocol == "http"
  | STATS violations = COUNT(*) by destination.ip, tls.version

1.2 Requirement 8.3: Non-MFA Authentications

Goal: Identify successful logins to the CDE that bypassed MFA.

buildEsql: (indexPattern, from, to) => `
  FROM ${indexPattern}
  | WHERE @timestamp >= "${from}" AND @timestamp <= "${to}"
  | WHERE event.category == "authentication" 
  | WHERE event.outcome == "success"
  | WHERE user.roles : "*admin*" OR data_stream.dataset : "*cde*"
  | WHERE mfa.enabled == false
  | STATS insecure_logins = COUNT(*) by user.name, source.ip

1.3 Requirement 8.3.6: Account Lockout (The "Compliance" Version)

Goal: Check for more than 6 failed logins (threshold before the 10-attempt lockout limit).

buildEsql: (indexPattern, from, to) => `
  FROM ${indexPattern}
  | WHERE @timestamp >= "${from}" AND @timestamp <= "${to}"
  | WHERE event.category == "authentication" AND event.outcome == "failure"
  | STATS failed_attempts = COUNT(*) BY user.name, source.ip
  | WHERE failed_attempts > 6
  | SORT failed_attempts DESC

It’s important to notice that those queries are much more complex, and often look for fields which are not necessarily part of ECS. A challenge here would be to expect clients to inject those fields to begin with in order for us to check them. It’s one thing to query over data coming from known Elastic integrations like Okta, and its a much bigger challenge to query over any data coming from the customer. 

2. The Data Quality & Integrity Problem

Compliance is only as good as the data quality. We need to add a data check before each query to even evaluate properly. If a client's logs don't follow ECS (Elastic Common Schema), our violation queries will return 0, giving a "False Green" because we simply couldn't find the fields.

2.1 Field Fill Rate Check

Before running compliance checks, the agent should run a pre-flight integrity check:

FROM logs-*
| WHERE @timestamp >= NOW() - 24h
| STATS 
    missing_user = COUNTIF(user.name IS NULL),
    missing_outcome = COUNTIF(event.outcome IS NULL)
  BY data_stream.dataset
| EVAL quality = ((COUNT(*) - missing_user) * 100.0) / COUNT(*)
| WHERE quality < 90.0

2.2 Data Duplication & Re-indexing

We also need to consider data duplication. During a re-index process, if the agent counts the same log twice, Requirement 8.3.6 (Lockout) might report a "False Red" because it thinks there were 12 failed attempts when there were only 6.

• Recommendation: We should provide users with index filters so they can specify exactly which indices to audit, avoiding overlapping patterns. We also need to ensure the agent handles deduplication by event.id where possible.

2.3 Timeframes & Sliding Windows

If a check runs over the last 24h but an attacker hits 4 times at 11:00 PM and 4 times at 1:00 AM the next day, they've exceeded the threshold of 6, but the daily query would miss it.

• Recommendation: We should allow users to apply custom time frame filters. Instead of a fixed 24h window, we need to implement sliding lookback windows (e.g., 48h or 7d) to catch "low and slow" attacks that bypass shorter query ranges. 

• A challenge here is that each query can potentially require a different timeframe, I suspect there’s no one size fits all solution her

[patrykkopycinski]

/ci

[kibanamachine]

💚 Build Succeeded

• Buildkite Build
• Commit: 16e5629

Metrics [docs]

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
securitySolution	152.0KB	152.1KB	+29.0B

Unknown metric groups

References to deprecated APIs

id	before	after	diff
securitySolution	564	566	+2

Unreferenced deprecated APIs

id	before	after	diff
securitySolution	564	566	+2

History

• 💔 Build #438687 failed 7f08ad9
• 💚 Build #438654 succeeded 39103fd
• 💚 Build #438625 succeeded 41e5257
• 💚 Build #438598 succeeded 72e7b83
• 💚 Build #438017 succeeded 73faf51
• 💛 Build #435787 was flaky dc000af

cc @smriti0321