SARIF: When Security Findings Become Agent Inputs

The Report Becomes an Input

OpenAI documents that Codex Security can investigate existing SARIF reports against repository context, alongside other vulnerability reports. It can examine claims, trace relevant code paths, and identify whether evidence supports action or requires further review. OpenAI describes exporting SARIF into delivery workflows and retaining engineer review of proposed changes. These are documented workflow capabilities, not guarantees that every imported claim is correct. [2]

A finding can inform investigation, remediation, or delivery. The receiving agent needs the claim, its scope, and uncertainties.

Luminity’s architectural interpretation: structured findings become more consequential when software can act on them. SARIF offers a shared representation at that handoff, growing in importance with the decisions downstream consumers influence.

What Can Travel With a Finding

SARIF can represent tool identity, rules, locations, code flows, proposed fixes, and repository revisions. Invocation objects record execution success and notifications. Many contextual fields are optional: the standard’s capacity does not establish what a particular producer actually supplies. [1]

Does the exported record carry enough information for the next permitted enterprise action?

Luminity recommends preserving that connection through triage, remediation, and verification. Record the producer and revision, distinguish observations from conclusions, and retain the evidence needed to challenge the claim. Link subsequent work to the originating record.

A Small SARIF Example

This illustrative SARIF log uses fictional tool, repository, revision, and finding values. It is not actual Codex Security output or an example of Microsoft’s draft AI profile. The structure uses standard SARIF fields. [1]

{
  "$schema": "https://docs.oasis-open.org/sarif/sarif/v2.1.0/errata01/os/schemas/sarif-schema-2.1.0.json",
  "version": "2.1.0",
  "runs": [
    {
      "tool": {
        "driver": {
          "name": "Example Scanner",
          "version": "1.0.0",
          "rules": [
            {
              "id": "SQL-INJECTION",
              "shortDescription": {
                "text": "Possible SQL injection"
              }
            }
          ],
          "informationUri": "https://example.org/"
        }
      },
      "versionControlProvenance": [
        {
          "repositoryUri": "https://example.org/repository",
          "revisionId": "0123456789abcdef0123456789abcdef01234567",
          "mappedTo": {
            "uriBaseId": "%SRCROOT%"
          }
        }
      ],
      "invocations": [
        {
          "executionSuccessful": true
        }
      ],
      "results": [
        {
          "ruleId": "SQL-INJECTION",
          "level": "warning",
          "message": {
            "text": "Request input may reach a SQL query; investigate validation."
          },
          "locations": [
            {
              "physicalLocation": {
                "artifactLocation": {
                  "uri": "src/search.py",
                  "uriBaseId": "%SRCROOT%"
                },
                "region": {
                  "startLine": 42
                }
              }
            }
          ]
        }
      ],
      "originalUriBaseIds": {
        "%SRCROOT%": {
          "uri": "file:///example/repository/"
        }
      }
    }
  ]
}

The record starts an investigation. It contains no reproduction evidence or coverage statement, and grants no permission to change code. A receiving agent should check the claim against the repository and preserve what remains unverified.

Try it: Download JSON as example.sarif, or save copied JSON with that filename. Open the SARIF validator screen, then drag the file onto “Drop your SARIF file here” or click to browse. [7] Microsoft’s SARIF Multitool checks schema and correctness rules locally or in CI. [6] The NIST SARD validator adds SARD-specific requirements; this example will not satisfy its submission profile. [8] Format conformance does not prove a vulnerability.

Explore viewers and tools through the SARIF home page. [9] For worked examples, follow Microsoft’s SARIF Tutorials, starting with Introduction and The Basics. The tutorials explain the format; OASIS remains authoritative. [10]

© 2026 Luminity Digital, Inc. All rights reserved. SARIF is an OASIS standard. OpenAI technologies and guidance belong to OpenAI. Practitioner explanation and architectural interpretation by Luminity Digital.

View interactive visual

AI Provenance Needs More Than a Tool Name

Microsoft’s SARIF SDK repository includes a document explicitly marked Draft for AI-generated security findings. Its conventions distinguish AI detection, enrichment of another source’s findings, and synthesis across sources through ai/origin. These are project conventions built on SARIF property bags, not new OASIS requirements or established commitments from every consumer. [3]

An agent that explains a scanner’s finding has performed a different operation from an agent that discovers a new issue or combines several reports into a composite claim. Those operations should remain distinguishable in enterprise evidence.

The draft separates exploitability evidence from impact, with conventions for evidence references and remediation handoff notes. It also warns against blindly applying proposed replacements to a later repository revision. [3]

Luminity recommends retaining inspectable backing for assertions. A demonstrated-exploitability label should lead to the observation and conditions, not replace them. Provenance supports assessment; it cannot establish truth alone.

Interoperability Has Operational Limits

GitHub’s code-scanning documentation makes the consumer boundary concrete. It uses a supported subset of SARIF properties and imposes ingestion and display limits. Successful upload does not establish that every contextual field becomes available in the resulting alert. [4]

Finding identity requires integration decisions. GitHub uses partial fingerprints to correlate alerts and warns that uploads through its API without fingerprint data may produce duplicates. Microsoft’s draft AI guidance instead discourages producers from persisting partial fingerprints and assigns cross-run identity to the result-management system. These are different responsibilities to reconcile, not interchangeable instructions. [3][4]

Luminity recommends assigning ownership of correlation explicitly and checking the chosen upload path. Test what arrives, what is displayed, and what the downstream agent receives. Preserve the original artifact where the alert view omits evidence needed for investigation. Version custom conventions and document their handling by each consumer.

Boundaries: A Finding Does Not Grant Authority

SARIF does not independently verify a vulnerability, prove complete coverage, or authorize a code change. OASIS explicitly prohibits an automated consumer from executing a command line carried in a SARIF log from an untrusted source. [1]

Luminity extends that boundary into the agentic workflow: treat embedded commands, source excerpts, links, and handoff prose as supplied evidence. Evaluate them under the receiving system’s permissions and policy. A report can describe an action without granting authority to perform it.

Completion is separate. OpenAI’s GitHub Action documents distinct scan, policy, and report statuses. An incomplete scan leaves policy unevaluated; an unavailable or withheld SARIF path is distinct from an available report. A missing optional SARIF report can leave reporting partial without making the scan itself fail. [5]

For Luminity, that means the handoff must preserve uncertainty about the investigation itself. An empty finding list cannot substitute for coverage and completion evidence. Likewise, a later scan without the original alert should prompt examination of scope, configuration, and code changes before someone closes the issue as verified.

Enterprises should control access to exported evidence. OpenAI notes that security reports can contain source excerpts and vulnerability details. Retention and sharing decisions belong with the workflow owner. [2]