| Type of data | In an AI tool |
|---|---|
| open-source code | yes |
| code covered by a client contract | only in a company-approved tool |
| client personal data | never |
| keys, passwords, tokens | never |
One page of rules instead of a ban nobody follows.
Rules for using AI tools in a development team — so the speed-up does not come at the cost of control over code and data.
The team still works faster — just within known limits.
This is the starting point in many companies that ship fast and are regulated.
The team already uses AI assistants, usually without agreed rules. Code is produced faster, but no one checks what goes into the prompt, where the generated fragment comes from, or whether it passed the same controls as hand-written code.
We define the scope after an assessment — starting with the element that lowers your risk fastest.
Rules instead of a gray zone.
We establish what may be pasted into an AI tool and what never — taking into account client data and code covered by contracts. We put generated code through the same review process as hand-written code, without exceptions, because a fragment's origin does not change its risk. We tidy up the access of assistants and integrations, so they get only the permissions they genuinely need. We train the team on concrete examples instead of imposing a blanket ban no one follows anyway.
Each stage leaves you with a concrete result, not meeting notes.
What may be pasted into the tool and what never — taking client data into account.
ResultShort rules: what may be pasted into an AI tool, and what never
The same review process as for hand-written code, without exceptions.
ResultGenerated code under the same controls as everything else
The assistant and integrations get only the permissions they genuinely need.
ResultAssistant and integration permissions narrowed to what is needed
Concrete examples instead of a blanket ban no one follows.
ResultA team trained on examples from your own work
Implementation ends with working configuration and evidence, not a report full of recommendations. Here is an example.
| Type of data | In an AI tool |
|---|---|
| open-source code | yes |
| code covered by a client contract | only in a company-approved tool |
| client personal data | never |
| keys, passwords, tokens | never |
One page of rules instead of a ban nobody follows.
repos:
- repo: https://github.com/gitleaks/gitleaks
rev: v8.21.2
hooks:
- id: gitleaksA secret will not reach the repository, whoever wrote the code.
The tool gets only the permissions it actually needs.
Illustration. We choose scope and tools after the assessment.
We define the scope after a call and an assessment. Smaller engagements close in a few weeks; larger ones we split into stages, so the result is visible after the first.
Usually not to all of it. In most cases access to the build pipeline configuration and organization settings is enough. We define the scope in writing before we start.
Yes, but not full time. We need contact with someone who knows the system, and a review of our changes. The rest is on us.
We plug into what already works for you. Replacing a tool is the most expensive and least often necessary way to improve security.
No. We work with standards and tools your team knows or will quickly learn — not a proprietary method only we understand. Everything is documented and handed over.
We wire controls so they run in the background. If one starts blocking work, we tune it or move it to a different point in the process.