PR Review AI Privacy & BYOK
CodeStax separates deterministic pull-request analysis from optional AI processing. Organization administrators can choose the processing mode under PR Reviews → AI Privacy. When policy resolution succeeds, CodeStax captures the resolved snapshot for that review attempt so the review page can show which mode, provider, region, retention rule, and credential source were used.
Some setup failures can happen before a safe snapshot exists. CodeStax records attempt-bound failure evidence when the persisted policy is valid enough to do so; otherwise the review labels AI execution evidence as unavailable instead of inventing a provider, credential source, or policy snapshot. Deterministic analyzers and scanner layers continue, but the final gate remains inconclusive rather than reporting an unverified pass.
Processing modes
| Mode | Provider credential | When the selected provider is unavailable |
|---|---|---|
| Deterministic only | None | Deterministic analyzers continue; no review content is sent to an AI provider |
| CodeStax-managed AI | CodeStax-managed | The AI execution is recorded as skipped or failed; CodeStax does not silently switch to BYOK |
| Bring your own key (BYOK) | Active organization credential | The AI execution fails closed; CodeStax does not substitute a platform credential |
AI-enabled modes require an explicit provider allowlist. The current API accepts OpenAI, Google Gemini, and Anthropic as policy providers. When more than one is allowed, the route is selected deterministically in this order: OpenAI → Google Gemini → Anthropic. Repository overrides take precedence only when the organization permits overrides and the override provider remains allowed. CodeStax does not select a provider from JSON/list order.
The policy response reports readiness for that exact selected provider. In BYOK mode, a credential for a different allowed provider does not make the selected route ready. Availability of a particular model or regional endpoint still depends on the deployed integration and configuration. This documentation does not claim that every provider/model combination has been validated in a live customer environment.
Data-handling controls
The AI Privacy page is driven by a server capability catalog and only offers controls the deployed transport can enforce. The current deployed contract is:
| Control | Enforced value |
|---|---|
| Processing region | Global |
| Data residency | No residency guarantee |
| CodeStax source retention | Disabled (0 days) |
| OpenAI request storage | Disabled per request with store: false |
| Gemini or Anthropic provider logging | Must be permitted by policy because these transports do not provide an equivalent per-request opt-out |
Maximum prompt and total-context character budgets remain configurable, as does whether repository-specific overrides are allowed. If an older policy requests a region, residency, retention, or logging behavior the deployed transport cannot enforce, the admin console marks it unsupported and requires correction before saving. An AI execution with an unsupported effective policy fails closed.
“Global” is not a residency certification. Provider-side abuse monitoring, logging, and retention remain subject to the organization’s provider account settings and contract. Verify those external settings before making a contractual or regulatory claim.
The server capability catalog currently advertises only deterministic review, AI issue analysis, and review chat. It does not advertise patch generation. Historical execution evidence may still contain a legacy patch_generation purpose, which is labeled as legacy evidence rather than a current capability.
For governed PR review analysis with source retention disabled, CodeStax bypasses its local raw AI-response cache. Normalized findings, summaries, evidence, and review results are derived records and continue under normal review/account retention; retain_source: false is not an instruction to delete those records. This cache rule is scoped to governed PR review analysis and is not a blanket statement about every generic full-scan AI cache.
Organization credentials
Only organization admins and owners can list credential metadata or mutate credentials. Members can view the organization AI policy but cannot retrieve the credential inventory.
When an admin adds or rotates a credential:
- The browser sends the credential once over the authenticated API request.
- The backend envelope-encrypts it with authenticated additional data bound to the organization, provider, credential identifier, and key-encryption-key version.
- The API returns only safe metadata: provider, label, status, version, encryption-key version, timestamps, and a masked final four characters.
- The plaintext credential is not returned by read, rotate, revoke, or execution-evidence endpoints.
Revocation is version-checked. Future BYOK executions cannot use a revoked credential. If the exact selected provider no longer has an active organization credential, the route is not ready and execution fails closed; CodeStax does not silently choose a lower-priority allowed provider. Policy changes, repository override changes, and credential revocation also erase any replayable review-chat answer for the organization in the same transaction while preserving bounded non-content metadata.
Repository overrides
Repository overrides are disabled unless the organization policy explicitly enables them. An override can narrow or change supported fields for one tenant-owned repository. Its provider must remain inside the organization allowlist. CodeStax validates the merged policy before saving it and rejects an unusable result.
Execution evidence
The review detail page shows immutable, attempt-bound AI execution metadata when it is available:
- policy mode and version;
- provider, model identifier, and model revision when recorded;
- organization-owned versus platform-managed credential source without exposing the credential identifier;
- processing region, residency, retention, and prompt-logging settings;
- estimated versus provider-reported token counts;
- outcome, timestamps, and a bounded error code; and
- the policy snapshot hash.
Prompts, source code, provider responses, cache keys, and credential secrets are not exposed in this view. Evidence is requested for the exact review attempt and uses stable cursor pagination for older records. For older reviews with no execution record, CodeStax labels the evidence as unavailable instead of inferring that AI did or did not run.
Governed review chat
Review chat uses the same resolved organization policy but records a separate immutable review_chat execution. The evidence view distinguishes review chat from the original review_analysis execution and shows the exact review attempt, execution sequence, and outcome for each. A chat answer never changes the stored quality-gate decision and is not a merge approval.
The chat interface handles governance outcomes explicitly:
- 409 deterministic-only: the request is recorded as skipped and no external AI provider is called; the interface does not offer a pointless automatic retry.
- 402 plan or allowance: the interface directs the user to an organization owner and does not retry a non-transient entitlement decision.
- 429 rate or concurrency capacity: the interface honors a bounded
Retry-Aftervalue. A manual retry reuses the original request ID so it does not create a duplicate logical question. - 503 policy, credential, region, or provider unavailable: the attempt is terminal. A manual retry uses a new request ID and resolves the currently approved route again without switching provider or credential behind the policy.
- Connection loss or an unclassified response: the browser cannot prove that provider work did not start, so a manual retry reuses the original request ID. The interface accepts an answer only when its response request ID exactly matches the sent ID.
Chat error messages use fixed, low-cardinality product copy. Raw provider/backend exception text, credential identifiers, cache namespaces, prompts, and secrets are not rendered. Provider/model availability still depends on deployment configuration; these controls do not imply that a live request has been validated against every listed provider.
Chat questions and answers are held in the current page’s browser memory only. CodeStax does not write them to browser localStorage or sessionStorage, and the interface removes keys created by older browser-persistence versions when the review opens. Navigation aborts the browser request, fences the stale response from the next review, and a reload starts a fresh local chat view. If provider processing already reached the durable started boundary, it may continue server-side to a terminal result; browser cancellation does not claim provider cancellation. That terminal result remains governed by the captured policy, immutable execution evidence, and the encrypted output-retention contract.
The server does not retain completed chat answers as plaintext. It AES-GCM encrypts an answer at rest solely for idempotent response replay. Replay eligibility defaults to 600 seconds and configuration is bounded to 30–3600 seconds; the actual eligibility window is the earlier of that configured value and the route idempotency TTL. After eligibility ends, ciphertext cannot be replayed. Cleanup targets the next scheduled run within 300 seconds, making 900 seconds (15 minutes) the default operating target—not a hard physical-deletion deadline. An outage or delayed job can leave overdue ciphertext as cleanup debt until a successful run removes it. The capability response publishes the eligibility TTL and cleanup target/cadence rather than asking the interface to infer them. Terminal/provider-started non-content reservation metadata follows the configured metadata-retention job. Server retention is distinct from browser persistence: a chat answer can contain source-derived text even when organization source retention is set to zero. Immutable execution evidence remains the longer-lived audit record.
Operational checklist
- Start with Deterministic only and confirm analyzer and quality-gate behavior.
- Review the provider contract for residency, retention, and logging terms.
- Add an organization credential before selecting BYOK.
- Select only the providers the organization has approved.
- Run a test review and inspect AI privacy execution evidence on that exact attempt.
- Rotate and revoke credentials through CodeStax; never place provider keys in repository files, pull-request text, or CI logs.