Skip to main content

ServiceNow Integration — W1

This document defines how the ServiceNow integration supports W1: Agentic AI Exposure Discovery & Assessment by extracting first-party, evidence-backed artifacts from ServiceNow that W1 uses to perform deterministic exposure evaluation.

This document defines data discovery and normalization only. Exposure evaluation logic is defined in product/wedges/w1-exposure/.

1. Purpose​

The ServiceNow integration exists to:

  • Inventory autonomous execution units on the ServiceNow surface (bounded to in-scope automation categories).

  • Provide deterministic artifacts that allow W1 to:

    • validate proof of execution (when possible),
    • bind execution to a standing-authority identity (when possible),
    • classify first observable data reachability and egress boundaries (when possible),
    • validate ownership status (when possible).

The integration does not evaluate exposure, assign risk groupings, or infer outcomes; it only contributes source artifacts to W1’s evaluation layer.

2. Execution surface​

The ServiceNow execution surface in scope for W1 is defined in automation-types.md. This is the authoritative reference for what qualifies as an in-scope ServiceNow automation category for W1.

3. Categories of data extracted​

W1 requires multiple categories of first-party ServiceNow artifacts. This section describes what kinds of artifacts the integration extracts, without adding fields beyond what the source materials define.

3.1 Automation metadata​

Artifacts that identify and describe in-scope ServiceNow automation constructs on the W1 surface, including the categories defined in automation-types.md (e.g., Business Rules, Script Includes, Flows/Workflow artifacts, Scheduled Jobs).

Note: Where the source material names ServiceNow constructs/tables for these categories, those names are used (e.g., Business Rules in sys_script, Script Includes in sys_script_include, Scheduled Jobs in sysauto_script).

3.2 Identity binding artifacts​

Artifacts required to deterministically resolve what identity the automation executes as, based on standing authority:

  • ServiceNow-side authentication / authorization configuration associated with an automation (where ServiceNow exposes deterministic references).
  • Cross-artifact linkage that supports chains such as: ServiceNow automation → outbound configuration → auth entity → external identity object.

Identity binding outcomes in W1 are explicitly bound or unknown when deterministic resolution cannot be completed.

3.3 Execution evidence artifacts​

Artifacts used to provide evidence-backed confirmation that an execution unit has executed, when deterministically linkable:

  • First-party execution records from ServiceNow that can be deterministically joined to a specific automation construct (by unique identifiers, without heuristic matching).

If deterministic linkage between an execution record and the automation cannot be established, W1 treats execution proof as unknown / unproven (explicit unknown, not inferred).

3.4 Egress configuration artifacts​

Artifacts that allow W1 to identify the first deterministically observable outbound endpoint associated with an execution-backed automation:

  • Outbound endpoint configuration exposed by ServiceNow automation chains (e.g., outbound request configuration referenced from an automation).
  • Endpoint identifiers sufficient to classify egress at the host/base URL level into LLM / External / Internal / Unknown, or none observed when no outbound endpoint is observable.

Egress is endpoint-level only and bounded to the first observable boundary. No payload/header inspection is performed or implied.

Artifacts required to validate whether each execution unit has an accountable, active owner:

  • ServiceNow automation metadata that supports provenance (creator) vs accountable ownership evaluation.
  • Ownership signals that can be deterministically resolved to identifiable owners (or explicitly labeled unknown/ambiguous/invalid when not possible).

W1 ownership outcomes are valid / invalid / ambiguous / unknown, and unknown is a first-class result when determinism is not satisfied.

4. Determinism constraints​

The ServiceNow integration must operate under W1 determinism rules:

  • Observed, not inferred: it provides observable first-party artifacts; it does not infer missing links.
  • First-party evidence only: inventory, identity binding, execution proof, reachability (first boundary), egress (first boundary), and ownership validation must be supported by first-party artifacts from supported surfaces.
  • Deterministic joins only: correlation across artifacts must use deterministic identifiers; no heuristic string matching or best-effort correlation.
  • Explicit unknowns: when deterministic linkage is unavailable, results must remain explicitly unknown (not backfilled).

5. Freshness model in W1​

W1 supports periodic collection and reassessment on a defined cadence (polling-based refresh). Outputs are “as of last refresh,” with no claim of immediate detection between refresh intervals.

6. What this document intentionally does not define​

This document does not define:

  • Exposure evaluation logic (qualification, identity binding rules, reachability computation, egress classification logic, ownership validity rules). Those are defined in W1 evaluation documents.
  • Any risk grouping scheme, scoring, UI behavior, roadmap, or coverage metrics.