Contents
Compliance
gitta runs in your own environment and gives you evidence for the controls auditors check when AI agents write code. This page maps each feature to those controls, so you can fill in a security questionnaire.
Where your data is
| Question | Answer |
|---|---|
| Does our code leave our environment? | No. gitta runs on your machines, and the team server runs in your own cloud account or cluster. Nothing is sent to gitta's company. |
| Does gitta use an AI model? | No. It sends nothing to any model. |
| What does the team server store? | The latest report per agent and the audit events. See Security and data. |
| Does the server call home? | No. It makes no outbound calls, except to your identity provider when SSO is enabled. The licence is checked offline. |
| Is gitta a subprocessor? | No. We never receive or process your data. |
SOC 2 and AI-generated code
SOC 2 asks for controlled changes to software. The main criterion is CC8.1, change management. It expects changes to be authorised, tested, approved and documented before they reach production. When agents write code, an auditor wants to see the same chain for each agent change, and to know which changes an agent made.
| What CC8.1 evidence needs | The gitta record |
|---|---|
| Who started the change | agent_started with the person, machine and tool |
| Which changes came from an AI agent | merge_checked and reached_main, with the commits and how many name an AI co-author |
| Tests before production | checks with each check, the test command and its result on the combined work |
| Weakened or skipped checks | warned, blocked and checks_skipped, with the findings and the person who ran the merge |
| A record nobody changed | The hash chain, gitta audit verify and the copies on the team servers |
Export the record for the audit period with gitta audit --csv. See Evidence for your auditor. Source: AICPA, Trust Services Criteria.
Controls
| Control area | What gitta does | SOC 2 | ISO/IEC 27001:2022 |
|---|---|---|---|
| Change management | Every merge to main is tested in combination with other agents' work. Each change is recorded with the person who started the agent. | CC8.1 | 8.32 |
| Secure development and testing | The merge stops when your tests fail on the combined code. An agent hears at once when another agent's change breaks the meaning of its new code. | CC8.1 | 8.25, 8.29 |
| Segregation of duties | Weakened tests or CI are reported with the person who merged them. In CI and the pull request check they stop the merge by default. | CC6.8, CC8.1 | 5.3, 8.32 |
| Security controls in code | Removed or switched-off authentication, authorization, CSRF, rate limit, validation and certificate checks are reported at merge time and recorded. Agents whose new code relies on a removed check are told at once. | CC6.1, CC8.1 | 8.25, 8.28, 8.32 |
| Secure coding | New code from agents is checked for well-known risks, such as SQL or shell commands built from text and variables and certificate checks turned off. The agent is told while it works. High-severity risks count as weakened checks at merge time, and each one is recorded. | CC8.1 | 8.28 |
| Secrets in code | What looks like credentials in code is reported at merge time. | CC6.1 | 8.28 |
| Logging | A hash-chained audit trail on each machine, with copies on the team servers that a machine cannot rewrite. | CC7.2 | 8.15 |
| Access control | SSO with OpenID Connect. A personal token for each person and CI runner, with expiry and revocation. | CC6.1, CC6.2, CC6.3 | 5.15, 5.16, 5.18, 8.5 |
| Supply chain | Each release has an SBOM in CycloneDX 1.6 and SPDX, for the binaries and the server image. See SBOM and CBOM. | CC9.2 | 5.21 |
| Use of cryptography | Each release has a CBOM that lists every algorithm, protocol, key and certificate, with the library and version. | CC6.1 | 8.24 |
| Encryption in transit | HTTPS between machines and the team server. | CC6.7 | 8.24 |
| Hardening and attack surface | On the clouds, the server is a unikernel with no shell and no SSH. The container runs as non-root on a read-only file system with no Linux capabilities. | CC6.6, CC6.8 | 8.9, 8.20 |
| Availability | Two or three servers in different zones. Warnings continue when one is down. | A1.2 | 8.14 |
| Monitoring of agent behaviour | Changes to agent instruction files are flagged, and gitta scan finds instruction files that a package planted in your dependencies. | CC7.1, CC7.2 | 8.16 |
For the audit events behind each row, see Audit trail.
EU regulations
The rules below ask organisations to control how their software is developed and changed. When AI agents write part of that software, gitta gives you controls and evidence for the development part. Your own processes, your product and your legal advice decide how you meet each rule. The references are to the official texts on EUR-Lex.
EU AI Act (Regulation (EU) 2024/1689)
The AI Act puts its duties on providers and deployers of AI systems. Most of them apply to high-risk systems, which Annex III lists by use, such as hiring, credit scoring or critical infrastructure. Record keeping in Article 12 is one of those duties. Whether any of this reaches the code your agents write depends on what you build and on your legal advice.
When you want a record of how AI agents took part in your development, gitta gives you one. It shows which changes an agent made, who started the agent, which checks ran and who merged each change. You can verify the record and export it. See Audit trail. Source: Regulation (EU) 2024/1689 on EUR-Lex.
Cyber Resilience Act (Regulation (EU) 2024/2847)
For manufacturers of products with digital elements sold in the EU. Reporting of actively exploited vulnerabilities and severe incidents applies from 11 September 2026. The essential requirements in Annex I and most other obligations apply from 11 December 2027.
| Requirement | How gitta helps |
|---|---|
| Annex I, Part I (1): products designed and developed with an appropriate level of cybersecurity | Every agent change is checked when it is merged. Weakened security controls, credentials in code and weakened tests are reported and, where you set it, stop the merge. See Warnings and sync. |
| Annex I, Part I (2)(a): no known exploitable vulnerabilities at release | New code from agents is checked for well known risks before it reaches main, and high risks count as weakened checks. |
| Annex I, Part I (2)(d): protection from unauthorised access | gitta flags when an agent removes or weakens an authentication or permission check that other code relies on. |
| Annex I, Part II (1): a software bill of materials in a machine-readable format | gitta ships CycloneDX and SPDX SBOMs for its own releases, so gitta itself fits into your SBOM. See SBOM and CBOM. |
| Annex I, Part II (3): effective and regular tests and reviews of security | The security checks and the combined tests run on every merge and every pull request, and each run is recorded. |
| Technical documentation and traceability | The audit trail records who started each agent, what changed, what was checked and who merged it. You can verify and export it. See Audit trail. |
The product side of the regulation, such as secure default configuration, security updates for your users, vulnerability reporting to ENISA and CE marking, stays with your own product process.
DORA, the Digital Operational Resilience Act (Regulation (EU) 2022/2554)
For banks, insurers, investment firms and other financial entities. It applies from 17 January 2025.
| Requirement | How gitta helps |
|---|---|
| Article 9(4)(e): documented policies, procedures and controls for ICT change management, including changes to software | Each agent change is checked, tested together with other work and recorded when it is merged. Risky changes are reported, and the record names the person who merged them. With gitta Enterprise, on mainframe code this includes new shell steps, authorised libraries and sensitive datasets in JCL, console and security commands in REXX, and any change to authorisation interfaces in assembler. See Security checks on mainframe code. |
| Article 9(4)(c): access limited to what legitimate and approved functions require | A personal token for each person and CI runner, SSO, expiry and revocation. See Tokens and sign-in. |
| Article 9(4)(d): strong authentication and protection of cryptographic keys | SSO through your identity provider. The cryptography gitta uses is listed in its CBOM. |
| ICT third-party risk | gitta runs in your own infrastructure. Your code is not sent to gitta’s company, and gitta uses no AI model. This keeps gitta out of the data path when you assess third-party providers. |
NIS2 (Directive (EU) 2022/2555)
For essential and important entities in the sectors the directive lists. Member States apply their national rules from 18 October 2024. Article 21(2) lists the minimum cybersecurity risk-management measures.
| Article 21(2) | How gitta helps |
|---|---|
| (d) supply chain security | SBOM and CBOM for gitta itself. Self-hosted, with no data sent to gitta’s company. |
| (e) security in acquisition, development and maintenance, including vulnerability handling | Security checks and combined tests on every agent change when it is merged. The audit trail shows which change introduced a problem and who merged it. |
| (h) policies and procedures for cryptography | The CBOM lists every algorithm and protocol gitta uses. |
| (i) access control policies | Personal tokens, SSO, revocation and an audit record of who did what. |
| (j) multi-factor or continuous authentication | SSO through your identity provider, so its multi-factor rules apply to gitta. |
Evidence for your auditor
- Export the audit trail for the period under audit.
$ gitta audit --since 2026-01-01 --csv > evidence-2026.csv - Show that nobody changed it.
$ gitta audit verify --team - Show your branch protection, with the gitta check required. See Pull requests and CI.
Security questionnaires
Send your questionnaire to [email protected]. We answer it for the software. Controls of your own environment, such as the cloud account the server runs in, stay with you.