Skip to main content

Surface: GitHub

Tools: GitHub Actions​

Scenario: Owner → Member responsibility change​

  1. A human (H) is an Org Owner
  2. As Owner, H:
    • creates an org-level secret (e.g., DEMO_PAT)
    • introduces a GitHub Actions workflow that uses this secret
  3. Later, H is downgraded:
    • Owner → Member
    • loses ability to manage org secrets
  4. No rotation, no re-approval, no ownership transfer occurs
  5. The workflow:
    • continues to run
    • continues to perform actions (e.g., create issues)
    • can be triggered by other users

What makes this important​

Nothing here is a bug.

GitHub behaves exactly as designed.

Yet the organization cannot answer, deterministically:

  • Who approved this execution now?
  • Is this execution still intended?
  • Who is accountable if it misbehaves?

That gap is the finding.

Why this is the right MVP focus​

1. It is real and reproducible​

  • Happens today in real enterprises
  • No edge cases, no exploits
  • Easy to demonstrate end-to-end

2. It avoids unproductive debates​

  • We don’t argue about token validity
  • We don’t claim bypasses
  • We don’t rely on access logs

Instead, we show execution continuity after authority decay.

3. It generalizes beyond GitHub​

This pattern is not GitHub-specific. GitHub is just the clearest first example.

What SecurityV0 delivers in the MVP​

For this scenario, SecurityV0 produces:

  • Identity
    • Autonomous execution (workflow + secret)
  • Authority
    • What the execution can do (API actions, repo scope)
  • Reach
    • Where it operates (org, repo, workflow, job)
  • Provenance
    • Who introduced it
    • What authority they had at the time
    • How that authority changed
  • Evidence pack
    • Raw metadata
    • Audit logs
    • Git history (blame)
    • Workflow execution metadata (run id, status, timestamps)
    • Cryptographic hashes

GitHub App Permissions for Deterministic Analysis​

Ideal permissions (full chain of custody)​

Required

  • Repository → Contents: Read
  • Repository → Actions: Read
  • Repository → Secrets: Read
  • Organization → Secrets: Read
  • Organization → Members: Read
  • Organization → Administration: Read (audit log; Enterprise)

Achieves

  • Confirms org‑secret usage inside workflows
  • Attributes introducer via audit log
  • Confirms current role (Owner/Member)
  • Proves Owner → Member downgrade with continued autonomous execution

Lower permissions (what breaks)​

Without repository contents

  • Cannot prove the secret is actually powering autonomous execution (no workflow evidence)

Without org/repo secrets

  • Cannot determine whether a secret is org‑level vs repo‑level

Without audit log

  • Cannot deterministically attribute who introduced the secret
  • Cannot prove the authority change timeline

No scoring.
No enforcement.
No UI required.

Why this matters to auditors and security leadership​

Auditors do not ask:

“Does this API call return 200 or 403?”

They ask:

“Can you demonstrate ownership, approval, and revocation of autonomous execution?”

Zombie NHI scenarios fail that test.

SecurityV0 gives organizations a defensible, factual answer—even when the answer is “we have no owner.”

Why this is a foundation, not a point solution​

The GitHub MVP is a pattern extractor, not a GitHub fix.

The same ownership-decay problem exists in:

  • GitLab CI/CD
  • Cloud build pipelines
  • Kubernetes jobs
  • Cloud scheduler workflows
  • Serverless functions with secrets
  • AI agents invoking tools
  • Agents spawning sub-agents dynamically

In all cases:

  • execution persists
  • authority drifts
  • human accountability erodes
  • evidence is fragmented or missing

SecurityV0 is designed to track execution lineage, not platforms.

Securityv0 — GitHub Agent Scope & Zombie Evidence Engine (v0)

Product Intent

Design Principles

Scope (v0)

In-Scope Identity Types

Out of Scope v0

Core Use Cases

Zombie / Orphaned Non-Human Identities

Agent Scope Creep (Level-1)

Functional Requirements

1 Identity Discovery

2 Deterministic Triggers (No Scoring)

A. Orphaned Ownership

B. Dormant Authority

C. Privilege-Justification Gap

3 Evidence Pack – The Deliverable

Output Formats

UI / Interaction Model

Must Have

Explicitly Forbidden

Success Criteria (v0)

Explicitly Out of Scope (Not Now)

Product Intent

Securityv0 v0 is a deterministic evidence engine that establishes audit-grade truth about non-human identities and agent scopes in GitHub.

It proves a class of governance failures that enterprises cannot currently explain:

  • Non-human identities with persistent authority and no accountable owner
  • Authorized agents whose effective scope exceeds their intended purpose
  • Latent, unaccountable blast radius over source code and CI/CD pipelines

v0 does not block, revoke, score, or remediate. Its sole purpose is to establish explainable, reproducible truth that a CISO, auditor, or board can stand behind. If a conclusion requires “trust me,” v0 has failed.

Design Principles

  1. Determinism over coverage: no ML classifiers, probabilistic judgments etc
  2. Explainability over enforcement: no prompt inspection, payload or code inspection, runtime blocking or revocation
  3. Evidence over dashboards
    • Outputs must plug into GRC, audits, and assessments
    • Human validation is expected (“trust but verify”) although not required
  4. Navigation over severity math
    • Findings must tell operators where to go and why
    • Risk scoring is secondary and optional

Scope (v0)

Environment: GitHub Organization, cloud-hosted for v0, but consider scalability for other options in the future. Read-only access

Deployment Model: SaaS App, explicit minimal scopes, metadata only to get the fastest approval path.

In-tenant or hybrid execution is explicitly out of scope for v0 but may be explored later.

Collect information on where additional scope / permissions will unlock more scenarios – this will be vNext.

In-Scope Identity Types​

Non-human identities only:

  • GitHub Apps (including AI and automation tools)
  • OAuth Apps installed at org or repo level
  • Personal Access Tokens used by services / machines, former contractors etc
  • GitHub Actions / OIDC identities associated with CI/CD workflows

Out of Scope v0​

  • Human users
  • Runtime activity interception
  • Payload, prompt, or code inspection
  • Multi-cloud or multi-SaaS correlation

Core Use Cases

Zombie / Orphaned Non-Human Identities​

A Zombie Identity is a non-human identity that:

  • Still exists
  • Holds meaningful authority (write, admin, workflows)
  • Lacks accountable ownership or justification
  • Persists beyond observable lifecycle signals

This is the entry wedge, not the ceiling.

Agent Scope Creep (Level-1)​

Scope creep is treated as a governance and explainability failure, not a prompt or content problem. v0 must surface cases where:

  • An identity’s effective permissions exceed its observable purpose
  • No evidence exists to justify the current level of authority
  • Scope creates latent blast radius even without malicious activity

Functional Requirements

1 Identity Discovery​

The engine must enumerate all in-scope non-human identities and capture:

  • Identity name and type
  • Creation timestamp (if available)
  • Creator (user, app, automation)
  • Current effective permissions
  • Accessible repositories
  • CI/CD or workflow associations
  • Last observed activity signal (reported, not judged)

All data must come from authoritative GitHub APIs.

2 Deterministic Triggers (No Scoring)​

An identity is flagged if one or more of the following conditions is true:

A. Orphaned Ownership​

  • PAT or OAuth token tied to a user no longer in the org
  • App with no attributable owning team, repo, or workflow

B. Dormant Authority​

  • No observed activity for a configurable window
  • Reported fact, not inferred intent

C. Privilege-Justification Gap​

  • Identity holds elevated permissions
  • No observable evidence supports the granted authority

All triggers must be rule-based and explainable.

3 Evidence Pack – The Deliverable​

1. Identity Summary

  • Name, type
  • Creation date
  • Owning user / repo / workflow (or lack thereof)

2. Authority Snapshot

  • Exact scopes and permissions
  • Repositories and workflows reachable

3. Provenance & Configuration Lineage

  • Where authority was granted
  • CI/CD, repo, or automation source
  • Relevant configuration references

4. Temporal Context

  • Identity age
  • Last observed activity (timestamped)
  • Ownership gaps

5. Validations Enablement: each finding must include enough information for a security operator to:

  • Locate the identity in GitHub
  • Identify the granting configuration
  • Manually validate or refute the finding

6. Deterministic Explanation in plain language, e.g.: “This GitHub App retains write access to 40 repositories, including CI workflows, despite no attributable owner and no observed activity in 37 days.”

7. Integrity Marker

  • Timestamp
  • Cryptographic checksum or signature

Output Formats

  • JSON (machine-readable)
  • Markdown or PDF (human-readable)

Evidence must be:

  • Time-versioned
  • Reproducible
  • Immutable once generated

UI / Interaction Model

Nice to have – UI exists only to support evidence review and navigation. Focus on the findings; we can command-line or JSON if needed for January.

Must Have​

  • Tabular view:
    • Identity
    • Trigger(s)
    • Scope summary
    • Link to evidence pack

Explicitly Forbidden​

  • Dashboards
  • Charts or graphs
  • Posture scores
  • Continuous alerting

CLI-first or minimal web UI is acceptable.

Success Criteria (v0)

Securityv0 v0 is successful if we can:

  1. Run against a real GitHub org
  2. Identify at least one non-human identity that:
    • Still holds authority
    • Lacks clear justification
  3. Produce an evidence pack that:
    • A CISO finds concerning
    • A security engineer can quickly validate
    • An auditor could include in an assessment
  4. Walk a design partner or investor through the finding end-to-end without interpretation

If any conclusion requires explanation beyond the evidence itself, the milestone is not met.

Explicitly Out of Scope (Not Now)​

  • Auto-revocation or kill switches
  • Policy authoring
  • Continuous monitoring
  • Multi-environment correlation
  • “AI-powered” analysis
  • Risk scoring as a source of truth