Sentinel overview
Understand Sentinel’s private-alpha, read-only repository review workflow and the boundaries among scans, findings, evidence, review, and proposals.
Sentinel overview
Sentinel is a private-alpha, read-only security-review surface for repositories the user owns or is explicitly authorized to assess. It organizes repository intake, scope, plans, findings, evidence, review, patch-proposal inspection, history, and readiness status without authorizing live-target scanning, credential testing, exploit automation, source mutation, pull requests, or external disclosure. Records can come from a store, demo seed, fixture, empty state, or unsupported path, and that provenance must remain visible.
What Sentinel does
Sentinel helps a reviewer examine an authorized code repository through a controlled defensive workflow. The landing surface labels the product Private alpha, Level 4-ready, and Authorized repositories only. That posture is narrower than a general-purpose security scanner and should remain clear on every related page.
The current product can guide source selection, authorization confirmation, local repository intake, scan-plan preview, supported read-only analysis, finding review, evidence inspection, triage, proposal review, history, and readiness status. It explicitly excludes live targets, credentials, exploit execution, destructive testing, automatic patching, pull requests, and disclosure actions.
A TypeScript action class is vocabulary, not proof of availability. The types include both defensive actions and prohibited or gated actions so that policy can classify intent. Documentation must not convert names such as apply_patch, open_pr, live_target_scan, or credential_test into executable features.
Sentinel reviews authorized repositories through a defensive, read-only private-alpha workflow. The landing surface labels Sentinel as Private alpha, Level 4-ready, and restricted to authorized repositories. The supported high-level sequence begins with source selection and authorization confirmation before repository scope is chosen. Local repository intake is available for private-alpha plan preview, while Git-provider connection and archive upload are planned.
The landing surface labels Sentinel as Private alpha, Level 4-ready, and restricted to authorized repositories; begin with an authorized repository and confirm the right to assess it. Policy decisions can be allow, deny, or requires_approval, with approval classes none, human_required, or blocked; use plans and preflight information to identify denied or approval-bound actions. Never describe Sentinel as an offensive-security platform or as permission to test a live target.
Scan lifecycle
The private-alpha lifecycle is intentionally narrow. Intake confirms an authorized source, planning defines repository scope and policy boundaries, and a supported scan path produces candidate findings with traceable references. Reviewers then inspect evidence and classification. The process ends with review information or a proposal artifact; it does not continue into source mutation, commits, pull requests, external disclosure, credential testing, or destructive activity.
The grounded sequence begins before scanning:
- Choose an intake source.
- Repository review starts with confirmed ownership or explicit permission.
- Select the authorized repository.
- Define or preview scope.
- Review preflight and policy decisions.
- Start only a supported read-only scan path.
- Review findings and evidence.
- Triage or inspect a patch proposal.
- Check history and readiness status.
Local repository intake is the available private-alpha path. Planned intake options include Git-provider connection and archive upload. A scan plan can describe proposed work without proving that every scanner, rule, or action will run.
Policy decisions can be allow, deny, or requires_approval. Sentinel uses three approval classes: none, human_required, and blocked. A denied or blocked action must not be bypassed. An approval requirement does not establish a universal persisted decision system.
The lifecycle begins with authorization and scope before any supported scanner activity. Policy decisions can be allow, deny, or requires_approval, with approval classes none, human_required, or blocked. Declared action classes include read-only analysis and prohibited or gated actions, but a TypeScript action name is not proof of executable capability. Findings and history can be store-backed or demo-backed; patch proposals currently lack a durable store.
Evidence model
Evidence links a candidate finding to repository or scanner context. Evidence records can include file paths, rule or scanner identifiers, summaries, and timestamps. A reviewer should be able to move from the finding to the supporting source within the authorized scope.
Evidence provenance matters. Sentinel loaders distinguish:
| Source label | Meaning |
|---|---|
| Store | Loaded from a backing record store. |
| Demo | Seeded example data for a demo environment. |
| Fixture | Static review material. |
| Empty | The path is supported but has no records. |
| Unsupported | The requested path is not available. |
Demo and fixture evidence must never be reported as a completed customer scan. Confidence in evidence is also separate from severity. Sentinel private alpha does not yet define a complete confidence model, fixed retention period, immutable archive, or export contract.
Evidence connects a candidate finding to traceable repository or scanner context. Evidence should retain traceable scanner or source references without implying a fixed retention period. Use plans and preflight information to identify denied or approval-bound actions. Inspect findings together with their evidence and data-source label.
Review workflow
Human review turns candidate findings into considered conclusions. Reviewers compare the summary, affected files, severity, evidence, classification, and current status. The product can present queues and records, but assignment persistence, comment persistence, notifications, role permissions, and service-level timers were not verified.
A status control in the interface is not enough to promise that every change persists across reloads or environments. The queue can also be store-backed or demo-backed. Read the source label before prioritizing or reporting a record.
Triage remains defensive. Sentinel does not authorize exploit validation against a live service or testing credentials to prove a finding. When more validation is needed, use an approved engineering or security process outside Sentinel’s current private-alpha boundary.
Human triage distinguishes candidate issues from reviewed conclusions. Treat patch proposals as review material only; do not expect Sentinel to apply or publish changes. Begin with an authorized repository and confirm the right to assess it. Demo and fixture records must not be presented as customer scan results.
Patch proposals
Patch proposals are suggested diffs for review. The loader explicitly states that no durable proposal store exists and currently returns demo or fixture material. A reviewer can compare the suggestion with the finding, evidence, and surrounding code, but the proposal is not an applied remediation.
Sentinel does not apply the patch, mutate the source tree, create a commit, open a pull request, or validate a production deployment. Even though those actions appear in the type vocabulary, those declarations do not make the actions executable.
A useful proposal review asks whether the change addresses the cited issue, affects behavior outside scope, introduces new risk, and needs additional testing. If the suggestion is useful, move it into the organization’s normal reviewed development workflow.
Proposals show suggested diffs for inspection and cannot change source code. Review the intended source state and scope before starting a supported local scan path.
Where to begin
Open Sentinel intake with a repository you own or have explicit permission to assess. Confirm the authorization boundary before selecting a local path. Review the generated scope and preflight information, and stop when the source type is planned, the path is outside scope, or policy denies the proposed action.
After a supported scan path produces records, check whether findings, history, and review queues are store-backed, demo, fixture, empty, or unsupported. Open evidence before accepting a finding. Treat patch proposals as non-persisted review aids.
Use /sentinel/status to understand current readiness and /sentinel/history to inspect available records. Continue to the repository connection and scan quickstart pages for task-oriented guidance. All Sentinel pages remain drafts because the product is private alpha and several schemas, persistence paths, collaboration controls, and retention behaviors require verification.
Start at intake with an owned or explicitly authorized local repository.