Know what Sentaryn Free can access and what it can do.

Implemented today

• Installable GitHub App; repository access is chosen through GitHub.
• Setup verifies the installation against the authenticated GitHub user’s accessible installations before obtaining repository identities.
• Repository discovery uses the specific verified installation; activation checks the repository against the setup session’s repository list.
• Sentaryn Free evaluates AI-generated changes; users review Shadow decisions in their GitHub workflow.
• Sentaryn Free publishes informational GitHub checks; it does not enforce decisions or configure merge protection.

Check the permissions GitHub displays

GitHub currently shows the Sentaryn App requesting these permissions during installation (September 18, 2026):

• Read: Code
• Read: Metadata
• Read: Pull requests
• Read and write: Checks

Repository access is controlled through GitHub installation settings. Review the permissions GitHub displays during installation; this dated list is not a promise that permissions will never change.

Setup uses GitHub user authorization to verify installation access and discover repositories for that installation. Those verification calls do not establish the App’s full permission set or webhook event subscriptions.

Least-privilege access is a design principle, not a claim that the App has the minimum possible permissions. Review the permissions before installing.

Install Sentaryn — review the access GitHub displays.

GitHub access and Sentaryn configuration

Select repository access through GitHub. In Sentaryn setup, choose a repository from the list obtained for the verified installation, review Sentaryn Free, and activate the configuration.

An installation ID supplied in a URL is a candidate to verify, not proof of access. Browser-supplied repository names and URLs do not establish authority; activation uses the server-held repository identity from the setup session.

Sentaryn repository activation does not change the App access granted through GitHub. Manage GitHub access in the relevant App installation settings.

Read installation and setup guidance →

GitHub setup information

• Candidate installation ID, GitHub OAuth callback code and state, and the user access token returned for verification.
• Installation identity, account login and account type returned by GitHub.
• Repository ID, full name and GitHub URL returned for the verified installation.
• Setup session cookie and the selected repository’s Sentaryn Free configuration.

Processing information does not mean every field is stored. The setup storage categories are listed separately below.

The evaluation service’s handling of pull request metadata, changed paths, diffs, file contents, source code and evaluation results is not documented here. This page makes no claim that source code cannot be accessed or stored.

Setup and configuration records

The website backend stores these setup records in Cloudflare D1:

• OAuth state digest, candidate installation ID, creation and expiry times, and consumption status.
• Setup session digest, installation ID, account login/type, creation and expiry times, and revocation status.
• Repository IDs, full names and GitHub URLs associated with the setup session.
• Activated repository configuration: installation and repository identity, plan, Shadow mode, policy, status, and creation/update times.

The separate website intake stores application details described in the Privacy Policy. The policy also covers GitHub setup and current Sentaryn Free use, while detailed evaluation-runtime data handling remains unresolved.

The Privacy Policy describes a general retention approach. Exact GitHub-product retention periods and deletion schedules are not documented. Session expiry limits session use; it does not promise deletion of stored records.

Implemented setup credential handling

The setup backend exchanges the GitHub OAuth code server-side and uses the returned user access token to verify installation access and discover repositories.

• In this setup flow, GitHub user access tokens and returned refresh tokens are not persisted in D1 or returned to browser JavaScript.
• OAuth state is stored as a digest, bound to the candidate installation, and accepted once within a 10-minute validity window.
• Setup sessions use a separate random token; D1 stores its digest. The session validity window is 20 minutes.
• The setup cookie uses HttpOnly, SameSite=Lax, a path limited to setup API requests, and Secure on HTTPS.
• Repository activation requires a same-origin request and a valid setup session.

These session windows are not GitHub token lifetimes or data-retention periods. Evaluation-service credentials and installation-token lifetimes are not documented here.

Informational authority evaluations

Sentaryn Free publishes informational GitHub checks named Sentaryn Shadow, created directly with a completed status. Shadow decisions do not enforce authority findings.

• WOULD_ALLOW maps to success.
• WOULD_REQUIRE_APPROVAL, WOULD_BLOCK and WOULD_NOT_VERIFY map to neutral. These authority findings do not produce a failure or action_required conclusion.
• Sentaryn does not configure branch protection or repository rulesets, or make its check required.
• Repository owners may require the Sentaryn check through GitHub settings. If required, a missing result can still prevent merging.
• It does not replace branch protection, code review, CI, tests, or security scanners.
• Keep existing GitHub protections and checks enabled; review Shadow as an additional authority signal.

Was the change authorized by the task?

Requested → Authorized → Actual → Evidence → Decision

Sentaryn compares what the task requested, what the agent was authorized to change, what actually changed, and the available evidence before reporting a Shadow decision.

• Tests ask whether behavior passes defined checks.
• Code review asks whether the diff is acceptable.
• Security scanners look for known security-risk patterns.

Passing tests do not prove authorization. An authorized change is not a guarantee of secure or correct code.

Setup rejects missing trust

• Invalid, expired or consumed OAuth state is rejected; GitHub verification failures do not produce an authenticated setup session.
• Missing, invalid, expired or revoked setup sessions cannot return trusted setup context or activate a repository.
• Activation rejects repositories outside the session list, mismatched installation IDs, cross-origin requests and unsupported configurations.
• If configuration storage is unavailable, activation returns an error rather than success.

These are setup safeguards, not a claim of system-wide fail-closed evaluation or merge enforcement. An unavailable evaluation should not be treated as authorization.

Sentaryn’s design principle is that missing evidence should not be represented as verified evidence.

Intake abuse prevention

The early-access form uses Cloudflare Turnstile. The intake backend checks the verification response, expected hostname and form action before storing a valid application.

This is a website-form control; it does not protect or verify GitHub evaluation. The intake database does not intentionally store visitor IP addresses, while infrastructure providers may process technical signals under their own policies.

The intake backend logs some verification and storage errors. This page does not claim that all infrastructure or evaluation logs exclude personal information.

Questions and access removal

Security questions can be sent to the existing public contact: legal@sentaryn.com.

You can remove Sentaryn’s GitHub access by uninstalling the App from the relevant GitHub installation. This does not establish deletion of previously stored records.

See the Privacy Policy for the existing privacy-request route and the Terms for their current scope.

Current limitations

• Sentaryn Free does not enforce decisions or configure merge protection. Merge eligibility remains subject to your repository rules, including any required checks.
• No guarantee that an authorized change is secure, correct or compliant.
• No compliance certification, formal audit, penetration-testing status or uptime guarantee is claimed here.
• No code-access exclusion, zero-retention policy, deletion guarantee or Sentaryn-controlled storage encryption guarantee is claimed here.
• Keep existing repository protections, review, CI and security scanners enabled.