Before connecting engineering context
Make the access boundary part of your decision.
Keep the reason behind work available to the right people. Review identity, repository selection and workspace permissions separately before sharing sensitive context with GitNative or an agent.
The public GitHub App declares these grants
Checked on 30 October 2026 for gitnative-dev. This is the public App declaration, not a readback of your installation. Confirm each grant and selected repository in GitHub before approving. A write grant does not mean a write runs automatically; review the workflows that need it.
| Resource | Grant | What to review |
|---|---|---|
| Contents | Read | Repository files and commit context |
| Issues | Read | Issue records |
| Metadata | Read | Repository identity and metadata |
| Pull requests | Write | The declared grant can modify pull-request records; it is broader than import alone. |
| Repository projects | Write | The declared grant can modify repository-project records. |
| Repository hooks | Read | Webhook configuration |
| User events | Read | App-declared user-event access |
Separate sign-in from repository installation
GitHub sign-in identifies an account. Installing the GitHub App is a separate step and can be deferred during onboarding. An organisation administrator may need to approve installation.
- Start with a test repository. In GitHub’s installation screen, review the actual read/write grants and choose selected repositories before approving.
- GitNative imports repository records including commits, pull requests, reviews, issues and contributors. Selected repository knowledge can also be indexed for workspace context.
- The installation screen is the authority for the installed App version’s exact grants. Do not infer a read-only grant from a list of imported record types. Ask support for an installation-specific permission review if the grants are unclear.
- Confirm your GitHub Enterprise deployment with support before connecting. These instructions do not establish support for every self-hosted Enterprise configuration.
Review who can see the imported context
GitNative checks current workspace membership, role and area permissions on the server. Project, team and record restrictions apply to supported retrieval and action paths. These controls need testing against your intended team and client boundaries.
- Use two test members with different roles. Check a public record, a restricted project and a private conversation before importing sensitive context.
- Repository selection limits what the installation can supply; it is not a promise that GitHub team permissions are copied into an identical GitNative access model.
- A connected agent acts under its credential owner’s access. Agent attribution does not expand that authority. Consequential operations require the applicable intent and confirmation checks.
Understand the key type before connecting an agent
A personal MCP key identifies one user across their accessible workspaces. Each request selects a workspace and rechecks current membership and permissions. Removing membership blocks that workspace; the same key can still work in other accessible workspaces.
- Legacy developer keys remain limited to their authorised workspace. Hosted OAuth connections are workspace-scoped.
- Review and revoke credentials in Settings → API Keys. Revocation stops future access; it does not recall data already returned to an agent client.
- Before a write, inspect the target, intended change and approval requirement. Preserve the credential owner, acting agent and human reviewer in your evaluation record.
Named services and data flows
The deployed architecture uses Cloudflare for Workers hosting and D1, KV and R2 storage, GitHub for connected identity/repository workflows, and Stripe for billing. This is a technical service map, not a complete contractual subprocessor register.
- Repository content and metadata enter GitNative only through an authorised connection or supplied content. Agent tool results are returned to the agent client you choose.
- AI-backed processing depends on the configured feature and model provider. Ask for the current provider, model, processing-country and contractual details for your intended workload before supplying sensitive data.
- Request the current subprocessor inventory and contractual terms from [email protected]. Confirm the actual processing countries and retention terms for your intended data.
Distinguish a region policy from a residency guarantee
Workspace region settings and migration history make the configured policy reviewable. Cloudflare location hints and jurisdiction options have platform constraints; a selected policy alone does not prove every copy or third-party process is physically in that region.
- Pro includes compliance documents, audit exports and data region controls. Check the selected workspace’s plan and actual configuration.
- For a residency review, request the storage location, processing locations, migration evidence, backup handling and third-party exceptions for the intended workspace.
Agree retention, deletion and the end of a pilot
Disconnecting a source or revoking a credential stops that access path; it is not automatic deletion of stored records. Retention depends on data type, workspace configuration and applicable agreements.
- Ask support for the applicable retention schedule, deletion process, backup expiry, legal-hold exceptions and export format before a sensitive import.
- Review deletion permissions and recovery windows in the product. A removed record and a permanently erased copy are different states.
- Use synthetic data to inspect an audit export or action trail before relying on it for an approval. Published controls do not establish a certification or a security guarantee.