Coding agents such as Claude Code and Cursor are now standard equipment in professional services: consultancies routinely run them against codebases their clients own. That shifts the risk model entirely. A mistake is no longer your outage, it is a breach of someone else's contract, data, and regulatory posture. This playbook covers the guardrails we put in place before an agent touches a client repository.
Why do coding agents need different rules on client code than on your own?
Because the blast radius belongs to someone else. On your own repository, an agent mistake costs you a revert. On a client repository it can leak their secrets to a third-party model provider, push unreviewed code toward their release, or violate their regulatory obligations. Consent, containment, and evidence stop being hygiene and become contract terms.
Three failure classes dominate in practice:
- ▸Data egress. Everything the agent reads can end up in a model API call: source code, config, comments containing personal data, credentials someone committed in 2019. Under GDPR, if personal data is in that stream, the model provider is effectively a subprocessor of your client's data, something your Article 28 data-processing agreement almost certainly never mentioned.
- ▸Unauthorized change. An agent with push access is a junior engineer with no fear and infinite stamina. Without hard gates, it will eventually commit something a human never saw.
- ▸Supply chain. The agent's own toolchain, MCP servers, extensions, auto-installed dependencies, becomes part of the client's attack surface for the duration of the engagement.
Each class needs its own control, and all three need paper: the client has to know and agree.
What should a client consent agreement for AI coding tools cover?
Name the tools and model providers, state what data leaves the client environment and where it is processed, pin the retention terms, and define who reviews output before merge. Get it in writing before the first session, typically as an annex to the MSA or SOW, with a per-repository opt-out.
The annex we use covers:
- ▸Named tooling. The specific agent products and model vendors, listed as subprocessors where client data transits them, with the hosting region stated.
- ▸Retention and training terms. Enterprise API agreements from the major model providers typically exclude customer inputs from training by default and offer short or zero retention windows, but the exact terms change, so cite the current version and date it.
- ▸Scope boundaries. Which repositories, branches, and paths are in scope; which are excluded outright (crypto code, HR tooling, anything with production data fixtures).
- ▸Human accountability. A named engineer owns every merged change regardless of who or what typed it.
- ▸Incident terms. What you notify, to whom, and how fast if the agent or its toolchain is implicated in an exposure.
- ▸Regulatory posture. EU AI Act transparency obligations for general-purpose AI are phasing in; hedge the language and verify against the Official Journal text and EU AI Office guidance rather than vendor blog posts.
How do you sandbox a coding agent so a bad action stays contained?
Run the agent in a disposable container with a read-only credential surface, a default-deny egress firewall, and no ambient access to anything outside the mounted workspace. Devcontainers with an outbound allowlist are the standard pattern; Claude Code ships a reference devcontainer that permits traffic only to an approved domain list.
The concrete checklist:
- ▸One container per engagement, rebuilt from a pinned image. Nothing persists between clients except the image definition.
- ▸Egress allowlist via iptables or a proxy: the model API endpoint, the package registry, the client's git remote, and nothing else. Default deny is what turns a prompt-injection attempt into a log line instead of an exfiltration.
- ▸Mount only the workspace. No home directory, no SSH agent forwarding, no Docker socket, no cloud CLI config. The agent should be unable to enumerate anything you did not deliberately hand it.
- ▸Non-root user, read-only root filesystem where the tooling tolerates it.
- ▸Permissive agent modes only inside this boundary. Auto-approval flags are defensible in a locked-down container and reckless anywhere else.
Scope the identity too: a fine-grained access token limited to the single client repository, expiring with the engagement. The reasoning mirrors what we laid out in Least Privilege for AI Agents: Scoping Tools, Tokens, and Blast Radius, assume compromise, then ask what the token could have done.
How do you keep client secrets out of agent context and model providers?
Never let secrets exist in the workspace at all. Keep env files outside the repo mount, inject short-lived tokens at runtime, add deny patterns for .env and key material to the agent's read permissions, and scan every commit with gitleaks or trufflehog before it leaves the sandbox.
Layered, because each layer fails sometimes:
- ▸Structural: secrets live in a manager (Vault, cloud-native stores) and reach the container as short-lived injected values, ideally via OIDC federation instead of static keys. If there is no .env file, the agent cannot read one.
- ▸Policy: deny rules in the agent's permission config for .env.pem, id_rsa, kubeconfig, and cloud credential paths; version that config in the repo so it is reviewable like code.
- ▸Detective: gitleaks or trufflehog as a pre-commit hook inside the sandbox and again in CI. Historical leaks matter too, scan history before the engagement starts, not after the agent has read it.
- ▸Data discipline: no production database dumps in fixtures, masked data only. The agent will happily read a customer table dropped into a seed file.
Remember the reverse direction: repository content is untrusted input to the agent. A hostile comment, README, or issue body can carry instructions, the mechanics are the same ones we walked through in Agentjacking Explained: How MCP Tool Poisoning Turns Your Coding Agent Into an Attacker. The egress allowlist is your backstop when injection lands.
What review gates belong between agent output and the client repo?
The same gates you would apply to a new contractor on day one: branch protection, mandatory review by a human who did not run the agent, CI that genuinely exercises the change, and merges blocked on secret scanning and SAST. Agent output enters the client repository through a pull request, never a direct push.
What that means concretely:
- ▸Branch protection plus CODEOWNERS on every in-scope repo, with the agent's identity structurally unable to approve its own work.
- ▸Attribution in the history. Co-authored-by trailers and an AI-assisted PR label. This is not ceremony, it routes reviewer attention and makes incident forensics tractable months later.
- ▸Small diffs as policy. A 2,000-line agent PR is unreviewable, and unreviewable means unmerged. Cap task scope, not just diff size.
- ▸Automated gates: Semgrep or an equivalent SAST pass, dependency review that checks registry age and download counts on anything newly added (hallucinated package names remain a live squatting vector), and license scanning, you are importing code into someone else's IP.
Tooling for the automated layer is a solved shopping problem, we compared the current options in AI Code Review Tools Compared for EU Engineering Teams: CodeRabbit, SonarQube, Sourcery, but none of it replaces the human gate; the failure modes are catalogued in The Hidden Risks of Shipping AI-Generated Code to Production.
What belongs in the audit trail for agent-assisted work?
Enough to reconstruct who ran which agent, with which model and permission set, against which commit, and what came out. Keep session transcripts, tool-call logs, the model identifier, and the resulting diff linked to its PR, retained per the client's evidence policy, typically twelve months or the contract term.
The artifact list:
- ▸Session records: prompts, tool calls, and outputs, exported per session and stored in the engagement's evidence space, not on an engineer's laptop.
- ▸Configuration as code: the agent's permission and deny rules, the container definition, and the egress allowlist, all versioned so you can state exactly what the boundary was on any given date.
- ▸Change linkage: every agent-assisted commit traceable to a session, a human owner, and a review.
This is the same change-management evidence an ISO 27001 or SOC 2 audit already expects, agents just make the volume higher and the authorship question sharper. Clients under NIS2 or DORA increasingly ask for it explicitly in vendor due diligence.
How do you handle MCP servers and third-party tools on client engagements?
Treat every MCP server as a dependency with code-execution rights. Run only servers you have pinned, reviewed, and allowlisted; block unvetted community servers outright. Tool descriptions are prompt-injection surface, so review them like code, and give each server the narrowest credential that still works.
- ▸Pin versions, disable auto-update for the engagement's duration; a benign server that updates itself mid-project is an unreviewed change to the client's attack surface.
- ▸Per-client credentials for any server that touches external systems, revoked at close-out.
- ▸Default to none. Most engagements need file, git, and shell access, which the agent already has natively. Every additional server needs a justification written down.
Our hardening checklist in Securing MCP Servers: A Hardening Checklist After the Exposed-Instance Disclosure applies double when the data behind the server belongs to a client.
How TuniCyberLabs helps
We run coding agents inside client engagements daily, under the sandbox, consent, and evidence model described above, and we help engineering organizations stand up the same guardrails for their own teams: container boundaries, permission policy, review gates, and audit tooling that survives a real vendor assessment. If you are introducing agents into regulated or client-facing work, talk to our engineers before the first session, not after the first incident.