Contents

Security and data

gitta runs on your machines and, with Enterprise, in your own cloud account. Your code never passes through gitta's company.

On a developer's machine

gitta reads the repository and its worktrees. It runs git and your gate command.
It writes its state to .gitta/ in the repository, and hooks and MCP entries to your agent tools' settings. See Agents.
Your code goes only to the team servers you configure. Once a day gitta sends its version, your operating system and your CPU type to gitta.io, and to GitHub when gitta.io is out of reach. GITTA_NO_UPDATE_CHECK=1 turns that off.
It has no AI model and sends nothing to one.

What the team server receives

Data	Sent	Kept
Files an agent changed, as at the agent's start and as now	At each agent step	The latest report per agent, in memory and in the server's data folder. Reports older than 6 hours no longer give warnings. Delete the data folder to remove them.
Agent name, machine name, repository identifier	With each report	As above
Audit events with paths, symbols, commits, results, person and machine	As they happen	Append-only, per repository, until you delete them
Files the agent did not change	Never	Never

A report is at most 32 MB. The server keeps no copy of the repository and does not merge anything.

Access

Every API call needs a token. The server refuses to start without admin tokens.
Personal tokens are signed, expire and can be revoked. SSO checks the identity provider's signature, issuer, application, expiry and email domain. See Tokens and sign-in.
The server stamps each audit event with the identity from the token. A machine cannot choose that identity.
Use HTTPS. See TLS.

The server itself

One static program written in Rust. It starts no other programs.
The container holds one program. It has no shell and runs as a non-root user, with a read-only root file system and no Linux capabilities.
On the clouds, the server is a unikernel VM with no shell, no SSH and no other programs.
The server makes no outbound calls, except to your identity provider when SSO is enabled.

Checks on agents

AI coding agents write code fast, and a reviewer reads only part of it. gitta checks every change an agent makes, while the agent works and again when you merge it. It uses fixed rules and your own tests. It sends no code to an AI model. The checks below run on every agent, in every language gitta reads.

What looks like credentials in code is reported at merge time.
Weakened tests and CI are reported in the merge output and the CI log, and recorded. In CI such a merge stops by default.
Removed or switched-off security controls, such as login, permission and CSRF checks, rate limits, input validation and certificate checks, are reported the same way. When another agent's new code relies on such a control, that agent gets a high-severity security warning at its next step. See Warnings.
New lines in an agent's change are checked for well-known risks, such as SQL or shell commands built from text and variables, unsafe loading of objects, certificate checks or CSRF protection turned off, weak password hashing and secrets in code or logs. The agent hears about each one while it works. High-severity risks count as weakened checks at merge time, and you can set the level. See Warnings.
With gitta Enterprise, on mainframe code, a change that newly runs shell commands from JCL, points a job at a system or authorised library, uses a sensitive system dataset, issues console or security commands from REXX, opens a network connection, adds dynamic SQL or a password, or touches an authorisation interface in assembler is reported at merge time and recorded. See Security checks on mainframe code.
Changes to agent instruction files such as AGENTS.md are flagged. gitta scan looks for instruction files planted in dependencies.
On Linux, agents can run in a kernel sandbox.

When a check fires

When	What happens
While the agent works	The agent gets a warning or a security note at its next step, in its own session.
On a pull request	The gitta check adds a Security line to its comment. See Security line.
During git merge, pull and push	gitta runs your tests on the combined code and stops the merge when they fail. Each check, stop and finding goes into the audit trail.

Your own security checks count too. List them in a committed .gitta-security file. See Mark your own security checks.

For SOC 2 and ISO 27001 mapping, see Compliance. For the software and cryptography in each release, see SBOM and CBOM.

Report a security problem

Send security reports to [email protected] with the word "security" in the subject.