Your coding agent became an infrastructure entry point: what to audit after the Claude Code/Cursor backdoor

I’m Denis Shokhirev, an Agentic AI Systems Architect in Freiburg im Breisgau, Germany, and I build production AI systems on Claude, Supabase, n8n, Doppler, and self-hosted Postgres. If your coding agent can read repos, touch secrets, suggest migrations, and interact with local tooling, the Claude Code/Cursor backdoor story is not a “developer productivity” incident anymore; it is an infrastructure access incident.

That distinction matters because most teams still classify coding agents as assistants. In practice, they sit close to source control, CI, package managers, shell commands, logs, and sometimes production-adjacent credentials. Once you accept that, the post-incident question changes from “Did the tool generate anything suspicious?” to “What did this thing have permission to see, suggest, and influence?”

1. Start with blast radius, not blame

The first thing I do after an incident like this is not grep for a bad snippet. I map access. Which repositories were visible? Which branches were writable? Which secrets were present in local environment variables, IDE settings, Doppler, CI runners, Supabase keys, or Postgres connection strings? If your team cannot answer that quickly, you have an access inventory problem before you have a code review problem.

OWASP’s “LLM Top 10” highlights excessive agency as a recurring risk pattern: model-connected systems are often granted authority beyond what their task requires. Source: OWASP GenAI Security Project, 2025, https://genai.owasp.org/. That maps directly to coding agents. The model output is only part of the problem; the bigger issue is over-permissioned context around it.

2. Rotate secrets before you finish the forensic story

If the agent had access to secrets, treat them as potentially exposed. Don’t wait for perfect evidence. In production, delayed rotation is often more dangerous than an incomplete timeline. I usually split response into three waves: immediately revocable tokens, service credentials with downstream dependencies, and long-lived infrastructure accounts.

#!/usr/bin/env bash
set -euo pipefail

echo "Immediate rotation queue"
echo "1) Revoke Git access tokens"
echo "2) Rotate Supabase service role key"
echo "3) Rotate Postgres app password"
echo "4) Rotate Doppler service token"
echo "5) Re-issue n8n credentials"

for item in git supabase postgres doppler n8n; do
  printf "queued: %s\n" "$item"
done

echo "Restart workers and invalidate cached sessions"

The order matters. First close future access. Then rotate credentials that can break running systems. Then document what was exposed and for how long. If you work with regulated B2B clients, that sequence is also easier to explain to security and compliance stakeholders than a long technical postmortem with no containment step.

3. Re-audit code the agent already helped write

The quiet risk is not the latest generated diff. It is code that was accepted weeks ago and is already in production. I would prioritize database access layers, shell wrappers, CI helper scripts, file handling, and anything that transforms external input before storage or execution. On several recent agent-driven projects, I caught the same issue pattern repeatedly: string-built SQL in otherwise clean code.

OpenAI Cookbook materials on tool use and function calling consistently reinforce the same principle: application-side validation and constrained execution matter more than model-side intent. Source: OpenAI Cookbook, 2024, https://cookbook.openai.com/. The same rule applies here. You should trust controls around execution, not the confidence of generated code.

import os
import psycopg
from psycopg.rows import dict_row

conn = psycopg.connect(os.environ["DATABASE_URL"], row_factory=dict_row)

def get_order(order_id: str):
    with conn.cursor() as cur:
        cur.execute(
            "select id, status from orders where id = %s",
            (order_id,)
        )
        return cur.fetchone()

def update_status(order_id: str, status: str):
    with conn.cursor() as cur:
        cur.execute(
            "update orders set status = %s where id = %s",
            (status, order_id)
        )
    conn.commit()

At minimum, run semgrep, bandit, and gitleaks across active repositories, then manually review modules the agent touched most often. semgrep is useful for catching known insecure patterns across languages, bandit helps in Python-heavy stacks, and gitleaks remains a practical pass for committed secrets.

semgrep --config auto .
bandit -r app/
gitleaks detect --source . --verbose
git log --since="90 days ago" --stat -- '*.py' '*.ts' '*.sql'

4. Restrict execution context, not just prompts

One common reaction after a public issue is to rewrite the system prompt and call it done. That is mostly theater if the agent still has shell access, broad network egress, mounted secrets, and permission to write into trusted branches. Effective containment lives in runtime controls.

Practical baseline

I recommend four layers. First, run agent tasks in a low-privilege environment. Second, split read and write credentials by task. Third, block direct production database access from the environment where the coding agent runs. Fourth, require human approval for migrations, credential changes, and infrastructure modifications.

agent_runtime:
  git_access: read_only
  network_egress: allowlist
  database:
    prod_direct_access: false
    staging_role: read_write
  secrets:
    mount_env_files: false
    use_doppler_service_token: true
  approvals:
    require_human_for:
      - migrations
      - credential_rotation
      - infra_changes

If you use Supabase, separate service-role usage from regular application keys by execution context. If you run self-hosted Postgres, create a staging-only database user and avoid password reuse across environments. If you use n8n, review every credential object and webhook flow. In real systems, automation is often what turns a local tool compromise into a wider operational incident.

5. Logs and prompt history are part of the incident scope

Teams often inspect repos and secrets but ignore prompt logs, IDE extension logs, CI artifacts, and traces. That is a mistake. Those locations frequently contain SQL fragments, internal URLs, customer payloads, and raw tokens. In European B2B environments, that is not only an engineering issue; it may also trigger contractual and privacy obligations.

Anthropic’s documentation for tool use and API integrations repeatedly centers explicit control boundaries around what the model can call and what the application should validate. Source: Anthropic documentation, accessed 2026, https://docs.anthropic.com/. That mindset should extend to logging: only retain what you can justify, protect, and delete on demand.

FAQ

Should we disable coding agents entirely after an incident?

Not necessarily. If the tool creates real value, keep it, but rebuild permissions, rotate credentials, and reduce execution privileges first. Removing the tool without changing access design only delays the next incident.

Is read-only Git access enough?

It is a good starting point, not a complete answer. Read-only access still exposes architecture details, secrets hygiene patterns, internal endpoints, and historical context that can help an attacker or lead to unsafe generated changes.

Do we need to review every past PR touched by the agent?

Usually no. Start with a 60–90 day window and prioritize PRs that changed SQL, shell scripts, auth flows, CI logic, secret handling, or infrastructure-related code.

What is the minimum practical toolset for a fast audit?

For many teams, semgrep, bandit, gitleaks, and manual review of high-risk modules are enough to start. The exact mix depends on your language stack and your compliance requirements.

Is this only about Claude Code and Cursor?

No. This is a class of risk that applies to any coding agent or IDE-connected assistant with access to source code, execution context, and tools. Product names change; the control model does not.

Which stage in your LLM pipeline actually catches the most dangerous issues in production today: static analysis, runtime restriction, or human review before merge? I’d genuinely like to compare that with what I’m seeing across B2B agent deployments.

I run a free 30-min stack audit for DACH founders building AI in regulated markets. DM me on LinkedIn or write to @ger_dennis_ai.