Security and exact verification

Installing Morph Actions lets repository workflow code execute on Morph-managed infrastructure and lets the Morph GitHub App read or change specific repository resources. Review this boundary before installation.

Supported repository boundary

The supported launch path is a private repository with trusted workflow authors. Public repositories and untrusted fork pull requests are blocked by the onboarding backend and UI. Ephemeral machines do not make unreviewed workflow code safe: a job can still access credentials exposed to it, reach network destinations, run containers, and use host privileges during its lifetime.

A future public-repository mode would require a separate threat model and explicit opt-in covering forks, secrets, runner groups, egress, privileges, and approval policy.

GitHub App access

The reviewed Morph Actions release contract requests these repository permissions. GitHub shows the authoritative live permission list during installation; stop if it differs from this table or the reviewed release notes.

GitHub permission	Level	Morph feature that uses it
Metadata	Read	Identify and bind the exact repository and owner.
Actions	Write	List workflows/runs/jobs, dispatch workflow_dispatch, inspect exact job assignment, cancel an authorized queued smoke, and manage repository runner registration.
Administration	Write	Create short-lived repository runner registration credentials and inspect registered runners.
Contents	Write	Read workflow files and create reviewed migration commits/refs.
Pull requests	Write	Create and inspect the workflow migration pull request.
Workflows	Write	Update workflow files through the reviewed migration pull request.

Morph consumes these signed webhook events:

Event	Purpose
installation	Reconcile installation created, deleted, suspended, and unsuspended state.
installation_repositories	Reconcile repositories added to or removed from an installation.
workflow_job	Observe eligible job lifecycle and establish exact runner/job assignment evidence.

The live App also has legacy subscriptions for create, pull_request, repository, workflow_dispatch, and workflow_run. The runtime ignores those event payloads; they are not part of the onboarding or execution contract. repository_ruleset is not selected. App owners should remove the legacy subscriptions after reviewing the settings change, and customers should not depend on them. GitHub's installation screen and App settings are the authoritative source for the currently selected event list.

Morph does not need a user's GitHub token for the supported headless flow. GitHub installation tokens are minted server-side for the selected App installation and repository scope. Do not put Morph API keys, runner registration tokens, callback credentials, or cache credentials in repository configuration.

Runner trust and privileges

Each eligible job receives an ephemeral Linux runner instance. Workflow code should be treated as privileged within that instance: it can use Docker, passwordless sudo, and outbound network access available to the runner. The repository's workflow controls what processes run and what job-scoped GitHub tokens or secrets GitHub exposes.

Morph supplies short-lived, job-scoped runner callback and cache context where needed. A workflow can read values made available to its process, so secrets must be minimized at the GitHub workflow/job/environment level. Isolation between ephemeral instances does not protect a secret deliberately exposed to untrusted workflow code.

Workflow review boundary

Morph's analyzer proposes supported runner-label rewrites. It is not an exhaustive workflow security scanner. Before merging its pull request, review:

• event triggers, especially pull_request_target and fork behavior;
• GITHUB_TOKEN permissions and secret/environment access;
• third-party action provenance and mutable tags;
• containers, Docker sockets, sudo, network access, and external services;
• every changed runs-on label set; and
• every dynamic, reusable, incompatible, or unsupported job left unchanged.

Warnings in the analysis are useful evidence, not a safety certification.

Data path and ownership

Morph processes repository/install identifiers, workflow and job metadata, runner labels, lifecycle events, logs surfaced in Morph Actions, and billing correlation records. Workflow migration reads workflow files and, after an explicit request, writes a branch and pull request. Configured cache or snapshot features may persist job-derived artifacts beyond the runner instance; repository owners decide what workflows write to them and should not cache secrets.

Runner instance lifecycle, Actions run/event/log storage, caches, snapshots, and GitHub's own records are distinct data stores. This guide does not promise a fixed retention period for them. Morph product/privacy owners govern service-side retention and deletion; GitHub organization/repository owners govern GitHub records; customer administrators govern workflow artifacts, caches, snapshots, and repository secrets. Confirm contractual retention and deletion requirements with Morph before onboarding regulated data.

Morph Compute Units and the active organization's plan determine usage and billing. Use the Morph console and Plans as the current source of truth; copied shape prices or comparative savings claims are not contractual.

Exact verification predicate

A setup is verified only for one selected repository and one exact GitHub job. All of these must be true:

1. the normalized repository equals the selected repository;
2. the Morph execution status is succeeded;
3. assignment state is verified;
4. expected and actual GitHub job ids are both non-null and equal;
5. GitHub reports that same job completed with conclusion success.

The UI and headless API distinguish:

• Pending: assignment or execution has not reached a terminal result.
• Mismatch: the observed GitHub job does not equal the expected job.
• Orphaned: the execution lost a valid corresponding GitHub assignment.
• Failed: the selected execution or GitHub job failed/cancelled.
• Verified: every condition above matches.

A green GitHub run alone, Morph labels alone, or any unrelated organization run is insufficient.

Operational safety

Installation handoffs are short-lived, single-use, organization- and repository-bound capabilities. Invalid, expired, replayed, cancelled, or conflicting callbacks do not mutate tenant ownership. Logs, audit records, and support lookup use bounded outcomes and request ids; they must not contain raw state, cookies, GitHub/Morph tokens, or unsafe return URLs.

For recovery, use Troubleshooting. Preserve a successful GitHub installation unless revocation is required for security.