Connect a repository

Repository intake establishes authorization and scope before Sentinel can create a scan plan. In the private-alpha implementation, the grounded path is a local repository the user owns or has explicit permission to assess. Provider connection and archive upload remain planned intake paths; this guide therefore does not invent OAuth, provider permissions, archive validation, or live repository synchronization.

Prerequisites

Confirm that you own the repository or have explicit authorization to assess it. Authorization should cover the intended codebase and the planned scope. Access to a filesystem path, copied source tree, or shared machine does not by itself grant permission to conduct a security review.

Use a local repository that can be read without exposing unrelated directories. Know which branch or snapshot is being assessed and whether generated files, dependencies, secrets, or large binary content should be excluded. No universal exclusion syntax is documented; use only the controls exposed by the current intake surface.

Sentinel is defensive and repository-focused. Do not use intake as a route to scan live targets, test credentials, automate exploits, perform destructive checks, or disclose findings externally.

Repository intake requires ownership or explicit authorization and a source path within the approved assessment boundary. The intake sequence is choose source, confirm authorization, select repository, choose a scan profile, review preflight, and start a supported scan path. Connect Git provider is planned rather than a verified live GitHub or GitLab integration. Upload repository archive is also planned and should not be described as available.

The intake sequence is choose source, confirm authorization, select repository, choose a scan profile, review preflight, and start a supported scan path; confirm ownership or explicit written authorization before choosing a repository. Local repository scanning is the available private-alpha path for scan-plan preview; define a narrow assessment scope and review the preflight summary before proceeding. The current evidence does not support provider sign-in steps, archive-upload instructions, or remote repository mutation.

Repository access

The intake landing page distinguishes three source types:

Choose the local path when it points to the authorized repository. GitHub or GitLab connection is not a verified live integration in the supplied sources, and archive upload is not available. Do not provide provider sign-in, token-scope, webhook, synchronization, or archive-format instructions.

Local access should remain read-only from Sentinel’s perspective. The product can inspect repository content, build plans, and support analysis, but it does not gain permission to edit files, create commits, or publish changes.

The private-alpha path uses a local repository, while Git-provider and archive options remain planned. Local repository scanning is the available private-alpha path for scan-plan preview. Authorization must cover the repository and intended assessment scope; possession of a path alone is not sufficient permission. Sentinel excludes live targets, credentials, destructive tests, exploit automation, and disclosure actions.

Upload repository archive is also planned and should not be described as available; select the local source path only when it points to the intended codebase and does not expose unrelated directories. Sentinel excludes live targets, credentials, destructive tests, exploit automation, and disclosure actions; stop if the source is unavailable, authorization is uncertain, or the path resolves outside the approved repository. Connection success establishes intake visibility, not permission for unrestricted scanning or source changes.

Connection setup

For the verified local path, select a repository that the operator owns or is explicitly permitted to assess, then confirm that the path presented to Sentinel is the intended repository root. Keep the assessment read-only and limit access to the files required by the scan profile. If the repository is unavailable, incorrectly scoped, or not authorized, stop before plan generation.

The source selector must preserve its state label. Planned Git-provider connection and archive upload are not substitutes for the available local intake path. A planned card should lead to explanation, not invented OAuth, token, organization-selection, or archive-processing steps.

Open /sentinel/intake and choose the supported local repository path. Confirm authorization in the current interface, then select the repository and scan profile shown by the build. Review preflight information before starting any scan activity.

A safe setup sequence is:

1. Identify the local repository root.
2. Local intake is permitted only after ownership or explicit authorization is confirmed.
3. Select the repository through the intake surface.
4. Choose a profile only when its scope is understood.
5. Review the proposed repository boundary and policy outcomes.
6. Stop if the path, authorization, or source state is unclear.

The exact button labels and persistence behavior remain under UI review. Connection success means the product can prepare the source for the current workflow; it does not prove a durable provider connection or unrestricted scanner access.

Current setup is a bounded local intake flow rather than a live provider connection. Exact repository permissions, collaboration roles, and provider access scopes were not verified. Define a narrow assessment scope and review the preflight summary before proceeding. Stop if the source is unavailable, authorization is uncertain, or the path resolves outside the approved repository.

Authorization must cover the repository and intended assessment scope; possession of a path alone is not sufficient permission; define a narrow assessment scope and review the preflight summary before proceeding. The intake sequence is choose source, confirm authorization, select repository, choose a scan profile, review preflight, and start a supported scan path; treat planned Git-provider and archive cards as roadmap states rather than working connection choices.

Scope

Scope should be narrow enough to explain what Sentinel may read and what it must ignore. Repository root, included paths, excluded paths, and the chosen scan profile are separate decisions. If an included path falls outside the operator’s authorization, revise the scope before continuing rather than relying on a later finding review to correct the mistake.

Scope defines what repository content the assessment may examine. Keep it narrower than the filesystem access available to the application. Include only code and configuration covered by the authorization, and exclude unrelated repositories, personal directories, secrets, or production data.

The Sentinel types distinguish scope kind and scope verification state. A plan can use those values to describe whether the requested boundary is understood. The exact public field names and editing controls require verification, so document the concept without inventing a complete scope form.

Review generated plans for paths, rules, and actions that exceed the intended assessment. A plan entry is not self-authorizing. Return to intake when the repository or scope does not match the permission granted.

Scope should name the repository areas covered by the authorization and exclude unrelated paths. Treat planned Git-provider and archive cards as roadmap states rather than working connection choices. Confirm ownership or explicit written authorization before choosing a repository.

Exact repository permissions, collaboration roles, and provider access scopes were not verified; stop if the source is unavailable, authorization is uncertain, or the path resolves outside the approved repository. Upload repository archive is also planned and should not be described as available; confirm ownership or explicit written authorization before choosing a repository.

Permissions

Repository authorization is the primary permission boundary in this batch. Sentinel does not establish a full role or tenancy model for repository connection. Do not invent admin, reviewer, contributor, or provider-specific permission names.

Policy can classify actions as allowed, denied, or requiring approval. Approval classes can indicate no additional approval, human review, or a blocked action. Those declarations must not be used to override repository ownership or legal permission.

Read access does not grant permission to test credentials, attack live systems, modify source, publish a pull request, or disclose a finding. If the desired activity falls outside the private-alpha read-only path, use a separately authorized organizational process.

Authorization to read a repository does not imply permission for destructive or external actions. Select the local source path only when it points to the intended codebase and does not expose unrelated directories.

Connect Git provider is planned rather than a verified live GitHub or GitLab integration; treat planned Git-provider and archive cards as roadmap states rather than working connection choices. Authorization must cover the repository and intended assessment scope; possession of a path alone is not sufficient permission; select the local source path only when it points to the intended codebase and does not expose unrelated directories.

Troubleshooting

If intake fails, isolate the source and authorization issue before changing scan configuration.

• The repository does not appear: confirm that the local path exists and is accessible to the current Desktop or application environment.
• Only planned source cards are visible: use the local repository path; do not invent a Git-provider or archive workaround.
• Authorization is uncertain: stop and obtain explicit permission.
• The selected path includes unrelated content: narrow the repository root or choose the correct source.
• Preflight shows denied or blocked actions: do not bypass policy; revise the scope or stop.
• The interface reloads without a connection: persistence behavior is not fully verified, so repeat only the supported intake process and record the inspected interface state.

For internal support, provide the source type, safe path label, authorization status, selected profile, and visible error. Do not include repository secrets or sensitive source content. A connection problem does not justify moving to an unauthorized remote target.

Intake failures usually involve authorization uncertainty, unavailable source types, or an inaccessible local path.