Your next step
Let’s discuss your next AI project.
Tell us about your business, your tools and the task you want to improve. We will help you define a practical first step.
AI security
Client source-code security with Claude Code and Codex in software services
Protect client source code with explicit permissions, limited access, project separation, controlled MCP tools and human review of coding-agent changes.
Published 17 September 2026
Coding-agent security depends on explicit authorisation, limited access and verified changes. A developer's access to client source code does not automatically authorise Claude Code or Codex to process it. Review the contract, the actual data-processing mode and the actions available to the agent before starting a pilot.
Three questions structure the work: what can the agent read, where can that information go and what can the agent do? Answers must be demonstrated through configuration and tests, not only stated in a policy.
Operational framework prepared with AI assistance on 17 September 2026. It is not an audit of your environment or legal advice. Applicable obligations require review by your responsible specialists. The cover is an AI-generated conceptual illustration.
1. Obtain project-specific authorisation
Examine code ownership, confidentiality and contractual restrictions. Permission for a services company to develop software does not necessarily describe processing by an AI supplier. The project owner should clarify the permitted uses.
Record the repository, allowed data, provider, execution mode and permitted operations. The decision may exclude branches, attachments, fixtures or ticket categories. A vague general permission is difficult to enforce.
When review is incomplete, use an approved training repository or non-confidential scope. The pilot itself must not introduce the exposure it is intended to evaluate.
2. Map the real data flows
A locally running agent may read workstation files while requesting inference from a remote model. A hosted environment may execute commands on a repository copy. The interface location does not establish the location of all processing.
Map the repository, workstation or execution environment, model provider, connectors, terminal output and logs. For each flow, identify the information transmitted, stored and made accessible to other people.
Training use, retention and location are distinct questions. A no-training setting does not prove that no information is stored. A business subscription is neither client permission nor automatic compliance with the Moroccan context.
Connect this review to AI governance, with security and data-protection owners examining the terms that actually apply.
3. Separate clients and reduce privileges
| Risk area | Proposed control | Test |
|---|---|---|
| Multiple client repositories | Access limited to the authorised project | Refuse an out-of-scope repository |
| Local secrets | Remove unnecessary secrets and restrict reading | Refuse a prohibited dummy file |
| Network | Destinations limited to the task | Refuse an unapproved destination |
| Shared branches | Review and merge protection | Refuse a merge without required approval |
| Production | Separate credentials and access | No production access from the pilot |
| Connectors | Restricted tools and service accounts | Refuse an out-of-contract action |
Use dummy credentials and dedicated environments for these checks, not a real password or production database.
The Claude Code security documentation and OpenAI administration guidance are starting points for examining product controls. The existence of a control does not prove that your configuration enables it correctly.
4. Distinguish instructions from enforced controls
CLAUDE.md, AGENTS.md and task prompts can state conventions and exclusions. They do not replace access restrictions imposed by the environment. Repository content may itself contain malicious instructions asking an agent to leave the approved scope.
Treat files, tickets, comments and retrieved pages as information, not new authority. A comment asking for a key to be sent externally does not become legitimate because it appears in the agent's context.
Consider indirect capabilities too. Disabling a browser tool may not prevent a shell command from reaching the network. Control the underlying capability rather than only the visible tool name.
5. Protect secrets and test data
A Git-ignored file may still be readable by local processes. Reduce secrets in the execution environment and use dedicated pilot access rather than relying only on repository exclusion files.
Logs and test output deserve the same attention as code. A trace can contain a token, address or customer record and subsequently enter a conversation. Keep output proportionate and prefer synthetic fixtures.
If a secret is exposed, deleting a message is not sufficient incident handling. The responsible owner should follow the organisation's procedure, revoke or replace affected access as appropriate and inspect relevant activity. Training should teach immediate reporting.
6. Scope MCP connectors explicitly
An MCP server exposes additional tools. Identify its operator, authentication, visible data and the effect of each operation. Reading a record is different from sending an email or changing a customer ticket.
For the first pilot, expose only required operations. Define the approved source, useful fields, permitted action, expected result and necessary approval. Test refusals as well as successful requests.
The MCP business-software integration page explains this approach. A connector does not remove application permissions or the need to separate clients.
7. Keep human review and proportionate records
A pull request should show the change, executed checks and limitations. Review dependencies, scripts and configuration as well as the main implementation. Passing tests do not prove the absence of vulnerabilities or data leakage.
Traceability can create its own sensitive-data copies. Do not retain every prompt and output by default without considering purpose, access and retention. Record what is necessary for the defined review and incident needs.
The Claude Code deployment guide and Codex deployment guide connect these controls to operational ownership.
Prepare the minimum decision record
Before opening the pilot, collect scope authorisation, the data-flow map, access matrix, tested restrictions, incident procedure and the name of the person who can approve expansion. Include unresolved issues and explicitly excluded uses.
The decision may apply to one project or one task family only. Do not automatically reuse it for a new client, connector or execution environment.
In the Claude Code vs Codex comparison, treat unmet mandatory controls as exclusion criteria rather than weaknesses to offset with speed.
Frequently asked questions
Can local execution guarantee that no code leaves the workstation?
Not by itself. Examine model requests, tools, provider conditions and the complete architecture before making such a guarantee.
Is disabling training use enough?
No. It does not resolve retention, access rights, connectors, logs or the client's contractual conditions.
Should every project prohibit coding agents?
The decision depends on the risks and available controls. An approved training scope may be acceptable while a client repository remains excluded.
Organise a governance workshop
Hunter BI can help identify permitted workflows, required controls and expected evidence before a pilot. The workshop does not replace your organisation's legal and security approval.
