For platform, developer experience and security teams
A Git client you can put in front of a security review.
macOS 12+ · Runs as the signed-in user · No elevated privileges · Executes the endpoint's Git 2.38.0+ · Client-side policy engine · Local operation record
The two questions you have to answer about a desktop Git client
Platform and developer-experience teams get asked to standardise the client. Security gets asked whether it is allowed. Those are different questions, and most Git clients answer neither well.
“What can it do to a repository, and can we prove what it did?” Most clients execute destructive operations behind a confirmation dialog and keep no record. When something goes wrong on a shared branch, the reconstruction is manual and the evidence is circumstantial.
“What does it do with our source, our credentials and our identity?” The usual answers are a marketing page, a trust badge and a support ticket. That is not a control set, and a questionnaire response assembled from it does not survive contact with a reviewer.
Both answers should be structural, and both should be checkable without asking us.
What the endpoint build does, and what it cannot do
Each of these is observable on a managed machine in an afternoon, without taking our word for any of it.
It runs as the signed-in user
No elevated privileges, no daemon, no helper tool. Installation follows whatever packaging process you already use.
It executes the endpoint's Git
Version 2.38.0 or newer, already installed. It bundles no Git and downloads none, and it says so at launch rather than failing halfway through an operation.
Credential custody is explicit
Git transport continues to use the system credential helper or the user's own SSH keys. Explicit provider PATs remain separate from Git transport, while browser-authorized provider tokens stay encrypted at the GitAegis gateway and are not copied to the desktop. Git cannot block invisibly on a hidden password prompt.
Subprocesses are pinned
Git configuration is pinned per invocation, so a hostile value in a repository someone cloned an hour ago is not honoured, and external diff and merge tools are never run in any mode.
Its optional network surface is bounded and enumerable
A daily update check carrying no device identifier, account and AI requests when those features are used, and read-only GitHub or GitLab requests for a connection the user created. Local PAT reads go to the configured provider origin; browser-authorized reads use the account gateway. No telemetry, analytics or licence check gates local work.
Every mutation is journaled
Intent, risk level, the exact commands, the capsule taken first, and the outcome, on the endpoint, searchable, and written before the operation rather than after it.
Read morePolicy: what is enforced, and what the signature is worth
The failure mode of desktop policy is a settings file a determined user can edit. GitAegis’s policy engine evaluates a documented rule catalogue twice (when the plan is built, and again immediately before execution) covering protected branches, force push with no lease basis, a simulated preview before a destructive operation, --no-verify hook bypass, commit signing, permitted author domains, and branch and commit-message conventions.
Precedence runs organisation → team → workspace → repository, and a rule locked at a higher scope is not weakened by a lower one, so the resolved rule set is reviewable rather than emergent. Every override carries the actor and the reason: a policy with no override path gets routed around, and one with an unrecorded override path produces no evidence.
Precisely, because it matters in a review: the organisation document is verified before it is applied, and an unsigned document, one that fails verification, or one from an organisation the device is not bound to is rejected. That signature is a Ed25519 signature whose private key never leaves the service, so it is tamper-evidence, not a trust boundary. Asymmetric signing is what would make it one, and it is not what ships.
- Organisation
- Team
- Workspace
- Repository
A rule locked at a higher scope is not weakened by a lower one.
The resolved rule set becomes preconditions
Evaluated when the plan is built, and again immediately before the operation runs.
- Overrides are recorded
Where a rule permits one, the override carries the actor and the reason.
- The document is verified before it applies
Unsigned, failing verification, or from an organisation the device is not bound to: rejected. The signature is Ed25519, so a member holding the verification key cannot produce a document that passes.
The record, and where it stops
On the endpoint the Operation Journal holds every mutating operation with its intent, its risk level, the exact commands, its checkpoint and its outcome, and a reconciliation pass at launch marks transactions that a crash interrupted as requiring intervention, so an unfinished operation surfaces as an item to resolve instead of an unexplained repository state.
The Flight Recorder timeline covers what happened to the repository, including the ref, index, stash and worktree changes GitAegis did not cause. It records pointer-level truth: content edits to files show up in status rather than as events.
What does not exist: an organisation-level audit trail with configurable retention, legal hold, a date-range filter or a scheduled export to your SIEM. If your retention system of record has to be Splunk, Sentinel or Chronicle, this is not yet the feed for it.
Identity, provisioning and residency
Identity
GitAegis has optional individual account sign-in, but no enterprise identity layer. SAML, OIDC and SCIM are not implemented: there is no identity-provider configuration, provisioning interface, or directory-group mapping to a role.
Residency
Residency has nothing to place. Capsules, the journal and the timeline are written to the user’s application support directory on a device you manage, and nothing is transmitted, so there is no per-organisation region to configure and nothing sitting in a jurisdiction you did not choose.
Deprovisioning
Deprovisioning is therefore your existing endpoint process: the artefacts are files on a machine in your fleet, removable with the tooling that removes any other local artefact.
The data boundary
GitAegis local Git work needs no account and no service, and nothing in the Git path waits on a network. Your Git traffic goes directly to the remotes you configured, with your own credentials.
The control that matters for a review is what is never assembled into a request. There is no upload path for a repository, a capsule, a diff or a support bundle, so there is no configuration under which one is exfiltrated. The one feature that sends anything about a repository is the AI commit report: a signed-in user pressing a button on one commit, sending its metadata and changed file paths, never file contents and never commit message bodies. Any capability that changes this will change this paragraph first.
Security questionnaire summary
The answers a reviewer usually asks for, written so each one can be checked on a machine rather than believed. Where the answer is that something is not implemented, the row says so.
| Question | Answer |
|---|---|
| What is the product? | A native desktop Git client: a Rust core with a web-technology interface, distributed as a signed macOS application for macOS 12 or later, on Apple Silicon and Intel. There is no Windows build and no Linux build. |
| Does it bundle or download Git? | No. It executes the Git already installed on the endpoint, version 2.38.0 or newer, and tells the user at launch when it cannot find one instead of failing halfway through an operation. It never downloads a Git. |
| How does it authenticate to Git hosts? | It does not. Git does, with the endpoint's own SSH keys and the system keychain. GitAegis holds no copy of a credential outside the platform store. Subprocesses pin GIT_TERMINAL_PROMPT=0, so Git can never block invisibly on a hidden password prompt. |
| Does it execute code from a repository? | Git hooks run only under the user's own Git, as Git would run them; Safe Mode pins core.hooksPath=/dev/null so nothing in a freshly cloned repository runs while it is being diagnosed. Subprocesses pin GIT_CONFIG_*, so a hostile core.fsmonitor in a cloned .git/config is not honoured. External diff and merge tools are never run, in any mode. |
| Is source code transmitted? | No. File contents and commit message bodies are never sent by anything in the product, and there is no upload path for a repository, a capsule, a diff or a support bundle. The bounded optional paths are an update check carrying no identifier, account and AI requests when those features are used, and read-only GitHub or GitLab requests for a provider connection the user created. A local PAT calls the configured provider origin directly; browser authorization uses the account gateway. Git's own remote traffic continues through Git with the user's credentials. |
| Is there telemetry? | None. No analytics, no usage reporting, no crash reporting. A support bundle exists, is generated locally, is secret-scanned, and can have paths redacted before anyone sends it, and nothing sends it automatically. Two things are counted and neither is telemetry: the daily update check, which carries no identifier and reports nothing, and AI commit reports, which are recorded as usage against the account of the person who asked for one. |
| How is identity handled? | Sign-in is optional and never gates local Git or recovery. It is required for the AI commit report and browser-authorized provider connections; an explicit provider PAT and Git transport credentials remain account-independent. SAML, OIDC and SCIM are not implemented: no IdP configuration, no provisioning interface, no directory-group mapping. |
| What policy enforcement exists? | A client-side policy engine evaluates a documented rule catalogue at plan time and again immediately before execution: protected branches, force push with no lease basis, simulation required for destructive operations, --no-verify hook bypass, commit signing, permitted author domains, and branch and commit-message conventions. Precedence runs organisation → team → workspace → repository, and a locked rule at a higher scope is not weakened by a lower one. Overrides are recorded with the actor and the reason. It governs what GitAegis will do; it is not a server-side hook, and a user with a terminal is outside it. |
| What audit record exists? | On the endpoint: the Operation Journal, holding every mutating operation with its intent, risk level, exact commands, capsule and outcome, and recover_incomplete, which reconciles transactions interrupted by a crash at the next launch so an unfinished operation surfaces as an item to resolve. An organisation-level audit trail with configurable retention, legal hold and scheduled export does not exist. |
| How are destructive operations handled? | Every mutation is a transaction: intent, risk level, preconditions, the exact commands, a checkpoint, a rehearsal and a rollback plan. The recovery capsule is written to disk before the first command runs, and an operation whose capsule cannot be written is refused rather than warned about: no control in the interface waives it. git gc, git prune and git reflog expire are not implemented, so no code path in the product destroys recoverable objects. |
| How does it update? | The application reads one fixed release manifest 30 seconds after launch and then once a day. The request carries no device identifier, no version parameter and no query string, and the version comparison happens on the endpoint. Nothing installs on its own: the user presses Restart to update, and the downloaded archive must carry a valid signature against a key compiled into the binary or the install is refused. Two limits to plan around rather than discover. The manifest itself is not signed, so a compromised artifact host could misdescribe a genuinely signed build, which the updater answers in part by requiring the manifest to name the channel this binary was built for. And there is no staged rollout, no kill switch and no forced downgrade: a withdrawn release is answered by repointing the manifest, which protects endpoints that have not updated yet and not one that already has. If you need to control the rollout yourself, deploy the package with your own tooling. |
| Can data residency be specified? | There is nothing to place. This build stores capsules, the journal and the timeline on the endpoint and transmits none of it, and there is no per-organisation region setting anywhere in the product. |
| What certifications do you hold? | None, and none are claimed. No SOC 2, ISO 27001 or GDPR-compliance badge appears anywhere on this site. Practices are described; where an attestation exists it will be published with its report and its date, and not before. |
| Who are your sub-processors? | This build has none in the path of your data, because it sends your data nowhere. Any that a hosted service introduces will be published, with notice of changes, before that service handles anything. |
| How do we report a vulnerability? | security@gitaegis.com. Reports get a written response from a person, not an autoresponder. |
| What is in a support bundle? | Diagnostics generated locally: it is secret-scanned, paths can be redacted before it leaves the machine, and it is transmitted only when someone chooses to send it. Nothing about it is automatic. |
Deployment
Package
A signed macOS application, on Apple Silicon and Intel, installed through the packaging process you already run. There is no Windows package and no Linux package.
Prerequisite
Git 2.38.0or newer must be present on the endpoint. On macOS 12, Apple’s Command Line Tools ship 2.37.1, which is below the floor, so a managed Git install is part of the image.
Updates
The application checks one fixed release manifest daily and offers a newer build; it installs when the user presses Restart to update, and only after the archive’s signature verifies against a key compiled into the binary. What is absent is fleet control: no staged rollout, no kill switch, no forced downgrade, and no managed-configuration profile to distribute, so there is currently no supported way to pin a fleet to a version or to switch the check off centrally. If you need to control promotion yourself, deploy the package with your own tooling.
Removal
Uninstalling leaves local repositories untouched. Capsules and journals live in the application support directory and can be removed with your endpoint tooling.
Talking to us
Security review
Send your questionnaire to security@gitaegis.com. The summary above is written to answer most of it, and anything it does not cover gets a written answer from a person rather than a link to a page.
Pilots
You do not need an agreement, an account or a purchase to run one. The edition described here is free. Run it on the repositories you are actually worried about, with the policy rules you would actually set.
Licensing and procurement
sales@gitaegis.com. Tell us the shape of the rollout and what your paper requires, and you will get a straight answer about what exists today and what does not.
What this does not do
Volunteered, because a review finds these anyway
- GitAegis holds no certification claims. No SOC 2, ISO 27001 or GDPR-compliance badge appears on this site. Practices are described; attestations will be published with their reports when they exist.
- There is no SSO, SCIM, residency setting or audit export. No SAML endpoint, no OIDC client, no provisioning interface, no per-organisation region, and no scheduled export with retention or legal hold. If your standard requires those before a tool is approved, this build does not meet it.
- Client policy is not server-side enforcement. It governs what GitAegis will do; a user with a terminal is outside it. Pair it with protected branches, required reviews and server-side hooks on your Git host: GitAegis is designed to sit alongside those, not to replace them.
- A branch lease is a coordination control, not a distributed lock over your Git server.
- There is no on-premises GitAegis control plane. The desktop application runs entirely on the endpoint and needs nothing else; there is no server component you host, and none you can point it at.
- Recovery has a boundary. If a capsule was taken you can roll the operation back; if a Flight Recorder event captured a state hash you can roll back to it; if any reflog entry, ref, branch, stash or capsule references a commit, Lost Work can recover it. Outside those it cannot. Rebase state is not restored from a capsule, and config is captured as evidence rather than restored.
Questions security and platform teams ask
For teams and organizations
Rolling GitAegis out across an organization?
Send the questionnaire, scope a pilot on the repositories that worry you, and get a written answer about what exists today and what does not.
sales@gitaegis.com for licensing and procurement · security@gitaegis.com for questionnaires and disclosure.
What a rollout includes
Volume licensing
every seat under one agreement
SSO
sign-in through your identity provider
Policy enforcement
org rules applied as preconditions, before any command runs
Audit
actor, device, and timestamp on every entry