AgentGit is software for storing and integrating source code, often written by autonomous agents. We take integrity and isolation bugs seriously.
| Version | Supported |
|---|---|
main |
Security fixes land here first; unreleased changes are identified in the changelog. |
0.3.0-beta.7 |
Current patch release; use its binaries after the Release workflow completes. |
0.3.0-beta.6 and earlier prereleases |
Upgrade to the current patch release for the fixes to stream scopes, workspace concurrency and retention. |
AgentGit is beta software. The current repository metadata schema is 8;
ChangesetV1, tree manifest v1 and repository configuration format 1 remain unchanged.
The server control database is migrated independently; use the same server version across replicas.
Beta.7 introduces no storage migration relative to beta.6. Returning to beta.5 or older
requires the pre-upgrade backup, not opening the upgraded database with an older binary.
See compatibility and releasing.
There has been no independent external security audit. Keep backups (ag backup) and a Git mirror (ag git export).
Please do not open a public issue for security problems.
Report privately through GitHub: https://github.com/Paffin/AgentGit/security/advisories/new
If that page is not available to you (private reporting has to be enabled by the repository's owner, and this file cannot check that it is), open an issue that says only "I have a security report" - no details, no affected component - and a maintainer will arrange a private channel.
Include what you can: affected version/commit, steps to reproduce, impact, and a suggested fix if you have one. You will get an acknowledgement as soon as a maintainer sees it; this is a volunteer project, so we cannot promise a fixed response time, but we triage reports before feature work.
We are especially interested in anything that breaks one of the documented guarantees
(see docs/architecture/security.md):
- publishing or integrating something that is not what was verified (hash/ID confusion, non-canonical encodings that decode to the same value, TOCTOU between verification and commit);
- losing or silently reordering a stream update (CAS bypass, lost update, reflog divergence);
- bypassing policy: integrating without the required validation/approval/lease, reusing an attestation or approval for a different tree/head/policy version, forging an attestation or provenance record;
- writing outside a checkout (path traversal, symlink escape, planting
.git/.ag); - garbage collection deleting reachable data;
- denial of service through a small input (decompression-style amplification, unbounded allocation, quadratic behaviour in the object decoders or merge);
- tampering with the audit chain that
ag auditdoes not detect; ag-server: using a credential outside its scope (repository, stream, operation, run), escalating through delegation, a revoked or expired credential that is still accepted, reading or writing another repository, a quota or rate limit that does not hold;- a secret (token, key) that ends up in a log line, a response, a metric or an audit entry;
- supply chain: a release artefact that does not match its checksum or attestation, a workflow that can be made to leak a secret or publish from a pull request, a dependency with a vulnerability our code can reach that the gates did not catch.
These are documented trade-offs, not vulnerabilities:
- Local mode trusts the local user. Anyone who can write
.ag/can edit the database or the object store directly. Integrity checks (ag verify, the hash-chained audit log) make tampering detectable, not impossible; anchor the audit head hash somewhere you trust. Several users needag-server, which authenticates and authorises them. ag validate runexecutes the given command without a sandbox. Use it only for code you trust. To run untrusted code use anag-worker, whose sandbox shares the host kernel (it is not a virtual machine); its limits and untested parts are listed there. A way out of the sandbox is a vulnerability: please report it as described below.- Private keys are stored as
0600files and are not encrypted at rest; neither are the control database or the object store. See the hardening checklist. - Case-insensitive filesystems can merge two paths that differ only by case on checkout. (Aliases of
.gitand.ag-.GIT,.git.,git~1, ignorable Unicode - are rejected.) - A deployment that runs
ag-serverin plaintext behind a TLS-terminating proxy (server.allow_insecure_remote) is only as safe as the network between the two. - A caller with the permissions a repository role grants can use them up to the configured quotas; that is the quota doing its job, not a denial of service.
- There has been no external security audit.
Nothing here replaces a review or an audit, and each line says where it runs:
| What | Where |
|---|---|
| Vulnerable dependencies (RustSec, npm, PyPI, Go reachability), licences, SBOMs, pinned actions | security.yml: every change and daily; findings we accept are listed with an owner and an expiry in security/exceptions.toml (how) |
| Static analysis of Rust, TypeScript, Python and Go | codeql.yml: every change and weekly; an alert fails the job unless it is accepted in the same file |
| Fuzzing of every parser and decoder that takes untrusted bytes (20 targets) | fuzz.yml: 60 s per target on changes to the fuzzed crates, 15 minutes per target nightly; results in the security model |
| Coverage per crate, with floors; mutation testing of the five crates that must not be wrong | quality.yml; numbers in Testing |
| Compatibility with data older builds wrote | tests/compat/ (Compatibility) |
To harden a deployment, use the checklist.
We prefer coordinated disclosure: we will work with you on a fix and credit you in the release notes unless you ask us not to.