Honest Cheetah for GitHub: Privacy & Security

Last updated 2026-09-13. Covers app.honestcheetah.com.

The short version

Your planning data stays in GitHub. Honest Cheetah reads it with your own GitHub sign-in, every time, and writes to it only when you click a button that says so. What Honest Cheetah keeps on its own servers is the part GitHub has no place for: test cases, test runs and their results, the screenshots and recordings attached to them, and the metric history a board needs for a forecast. All of it is partitioned by your GitHub organization, stored in Microsoft Azure in the US East 2 region, and encrypted at rest and in transit. Your GitHub token is never written to our database.

How it's built

Honest Cheetah for GitHub is a hosted web application. There is nothing to install in your GitHub organization for the current product; you sign in with GitHub and the app reads your boards on your behalf.

Signing in, and what happens to your token

You sign in with GitHub. Honest Cheetah creates no accounts and stores no passwords; whatever GitHub requires of you, including two-factor authentication and single sign-on enforced by your organization, is what Honest Cheetah requires. The authorization asks for access to your repositories and Projects boards and to read your user profile and which organizations you belong to. The public listing is github.com/apps/honest-cheetah.

Which organizations you belong to is read from GitHub at sign-in and rechecked from GitHub about once a minute while you use the app. Most company organizations restrict which OAuth apps can see their data, and until an owner approves Honest Cheetah your organization simply doesn't appear. Nothing about it is read.

What it reads from GitHub, and when

Reads are live. There is no background sync, no webhook subscription, and no cached copy of your board: when you open a page, the app asks GitHub for what that page shows, using your token, and shows it. Close the tab and the reading stops. Specifically, the app reads:

Issue bodies and comments are displayed while you look at them and are not kept, with one exception: the Azure DevOps import holds work items in a staging area until it completes (below).

What it writes to GitHub

Nothing, until you click a button that says it will. Every write uses your own token, so in GitHub's history it was you. The things Honest Cheetah writes, each behind a button: issues and sub-issues, their statuses, iterations, and backlog order; a project board, repository, and sample backlog when you ask the project factory for one; a Bug issue filed from a failed test result; and the issues created by an import from Azure DevOps. The AI never writes; it proposes, and you click or you don't.

What it keeps on its own servers

Everything below is stored in Azure Cosmos DB, keyed by your GitHub organization's id, and belongs to that organization.

Verification
  • Test cases: title, steps, tags, priority, lifecycle, review disposition, every version, and the GitHub issue each one verifies.
  • Test runs and results: outcomes, per-step outcomes, notes, the name of who or what performed each result, who recorded it and through which channel, when, and what build or environment the run was bound to (repository, commit, workflow run id, pull request, or the text you typed).
  • Evidence records: for each screenshot or recording, its filename, size, which step it belongs to, who captured it, and when. The bytes live in the evidence store.
  • Suites, and a record of each bug filed from a run: the GitHub issue number and link, its title, and who filed it.
Planning and metrics
  • Metric history: one record per completed item, with its issue reference, title, completion date, and cycle and lead time in days, labelled with where it came from (imported from Azure DevOps, or generated sample data). Live completions are computed from GitHub when you look, not stored.
  • Project settings: which statuses mean started and finished, the Definition of Done text, and each user's pinned projects.
  • AI results: the review findings and suggested text for a requirement, and the verdict on whether a project has enough context for a draft. Each is tied to the issue it is about and to the version of it that was reviewed.
  • AI usage: per call, the organization, the user, the feature, the model, and token counts. Not the prompt, and not the response.

Titles of GitHub issues are kept alongside the records above so that a test run or a metric row is readable after the issue changes. Nothing else from GitHub is copied.

What it does not keep: issue bodies or comments (outside an import in progress), source code, pull request contents, GitHub tokens, passwords, or anything from an organization you haven't opened in Honest Cheetah.

Screenshots and recordings

When you attach a screenshot or record your screen during a test run, the browser uploads the bytes straight to a private container in Azure Blob Storage under a short-lived upload link the data service hands out for that one file. Nobody outside Honest Cheetah can list or read the container. Evidence is served back only through the app, to people who can see the organization it belongs to.

What the AI sees

AI features call Anthropic's Claude models over Anthropic's API. Each call sends what that feature needs and no more: the requirement in front of you (title and body), its test cases if the feature is about them, the project's description, README, and agent instruction files for context, and, for the metrics explainer, the numbers Honest Cheetah already computed. The model never sees your code, your other organizations, or anything Honest Cheetah stores for anyone else.

Importing from Azure DevOps

The import reads a team project with a personal access token you create in Azure DevOps with read-only scopes. The token is held in the browser tab and sent as a header on each read request. The server keeps nothing between requests, the data service never receives it, and the log records a fingerprint of it, not the token. When reading ends, the token is forgotten; closing the tab has the same effect as revoking it.

The work items being imported (requirements, tasks, test cases, and shared steps, with their fields) are held in a staging area, partitioned to your organization, until the import completes or you discard it. On completion the staging area is reduced to an origin map, which work item became which issue or test case, and nothing else is kept. Nothing is ever written back to Azure DevOps.

Tenant isolation

Every stored record carries the GitHub organization it belongs to, and that value is the database partition key. The data service accepts a request only with a token from the app naming the user and the organizations GitHub says they belong to, and every query is scoped to one of those organizations. There is no cross-organization query path in the application. The demo organization is shared sample data that any signed-in person can browse; writes to it are refused.

Encryption and credentials

Hosting and data residency

ComponentProviderRegion
The app and the data serviceAzure App ServiceUS East 2
DatabaseAzure Cosmos DBUS East 2
Evidence storeAzure Blob StorageUS East 2
TelemetryAzure Application InsightsUS East 2
Sign-in and planning dataGitHubPer your GitHub plan
AIAnthropic APIPer Anthropic's terms

Microsoft, GitHub, and Anthropic hold their own compliance certifications (Azure, GitHub, Anthropic). Honest Cheetah's data residency is the US East 2 region; GitHub's is whatever your GitHub plan provides.

Logging and telemetry

When a trial ends, when you leave

GDPR

Questions

Privacy or security questions: support@honestcheetah.com.

Back to Privacy & Security