Find shadow AI in GitHub Actions

Find AI use in GitHub Actions by tracing workflow definitions, called workflows, third-party actions and invoked scripts, then checking runtime evidence for the relevant period. Record the repository owner, provider destination, credential source and business purpose. Keep configured capability and observed use as separate inventory states.

An AI-assisted code-review or release workflow can run without anyone opening an AI website. Browser discovery therefore needs a complementary view of automation. Start with a defined repository and runner scope, using read-only access and content-minimised evidence.

Follow dependencies beyond the first workflow

GitHub's reusable-workflow documentation explains how one workflow can call another, including nested calls. Inspect the workflow reached by each reference and the actions or scripts it invokes. Record dependencies you cannot access as unresolved.

Include organisation-owned reusable workflows, composite actions and shell or application scripts called by jobs. Search for declared AI providers, SDK dependencies and configured destinations as leads. A package name or an environment-variable name supports further inspection, with actual use still to be checked.

Preserve the workflow path and exact commit for each finding. A reusable workflow referenced by a mutable tag or branch can change while the caller stays unchanged. The inventory needs the version actually resolved for the period being investigated.

GitHub's secure-use reference recommends pinning third-party actions to full-length commit SHAs and auditing their source. The same guidance applies to reusable workflows. An immutable reference makes a review reproducible; ongoing updates and dependency review remain operational work.

Use built-in inventory as a starting point

GitHub documents dependency-graph support for actions and reusable workflows referenced through workflow uses fields. It can identify the owner, referencing workflow and pinned version. Check whether the graph is enabled and accessible for each repository in scope.

Follow invoked scripts separately. A program can construct a provider request at runtime, and its destination may come from an input or configuration file. Record how the destination is resolved without copying request bodies into the inventory.

An AI gateway adds another distinction: the visible destination may identify the intermediary while the selected model provider is set elsewhere. Ask the workflow owner for the approved route and supporting configuration. Keep an unresolved provider as an explicit gap.

For a bounded exercise, choose one fictional release-summary job. Trace the caller, reusable workflow, action and provider connection on paper. The inventory should retain that chain and the evidence supporting every step.

Establish what actually ran

Correlate a workflow run identifier, attempt, commit, job and time window with the available provider or gateway usage record. A job can be skipped, fail before its AI step or complete through a fallback. Successful workflow completion alone leaves those alternatives unresolved.

Use an evidence scale: configured dependency; executed AI-related step; corroborated provider request; and approved use with a named owner. Define what qualifies for each state. Report counts within the same observation window and access scope.

GitHub says organisations using Enterprise Cloud can monitor reusable-workflow use through the audit-log API. Check plan and permission availability before relying on that source. A missing event or inaccessible repository should remain a coverage limitation.

Compare this automation inventory with shadow AI evidence from billing. Billing can support a usage finding while still leaving the precise workflow or request unresolved.

Trace authority without collecting credentials

Record secret names and their owning scope only where needed for attribution. Inspect how the workflow passes credentials, the intended permissions and the responsible owner. Keep secret values, prompts and source-file contents out of the discovery report.

Reusable-workflow secret passing needs inspection at each call. GitHub documents named secret passing and inheritance, with secrets passed to directly called workflows. Follow the actual configuration through the chain and record the access granted at each step.

Also include short-lived cloud identity. GitHub supports OpenID Connect for workflows accessing compatible cloud providers. An inventory limited to long-lived API-key names would leave that route uncovered.

Treat raw logs as sensitive. GitHub's security guidance warns that transformations and structured secret values can interfere with redaction. Prefer bounded run metadata and reviewed event fields; authorise any deeper log access for a specific investigation.

Turn each finding into an owned decision

Ask the repository owner to confirm the task, data categories, permitted provider and retention expectations. Mark the workflow approved, awaiting review or outside the agreed inventory scope. Preserve the evidence date and review owner.

Test the discovery method against a controlled repository containing a direct provider call, a nested reusable workflow, a disabled job and a benign dependency that never invokes AI. Check that these cases receive different evidence states. No live employee workflow or commercial discovery product was tested for this guide.

Extend the same ownership model to employee tools using the workplace AI governance guide. Promptective's desktop packages and public self-serve browser extension are available for workplace AI protection; Amp uses its separate Managed Cloud integration. Assess automation routes explicitly when planning coverage.

Map your AI workflows with Promptective.