Who is accountable when source code is exfiltrated through a compromised developer account?

Why This Matters for Security Teams

When source code leaves a repository through a compromised developer account, the issue is rarely just “an account breach.” It usually exposes a chain of control failures across identity governance, developer workstation trust, secret hygiene, and repository permissions. The accountability question matters because response actions differ depending on whether the weak point was access provisioning, code hosting configuration, or failure to remove access after role changes. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls remains a useful reference for mapping those control responsibilities.

Security teams often get this wrong by treating the developer as the only accountable party, or by assuming the repository platform alone owns the risk. In reality, the application owner, IAM function, DevSecOps function, and sometimes platform engineering all share operational accountability for different control layers. If the account was used legitimately after compromise, the organisation also has to distinguish between identity failure and detection failure, because those are not the same corrective action.

In practice, many security teams encounter exfiltration only after the code has already been copied out, rather than through intentional monitoring of repository access and unusual session behaviour.

How It Works in Practice

Accountability should follow the control boundary, not just the incident headline. The developer may be the access holder, but the organisation is accountable for making sure the identity was issued correctly, the session was protected, and the access was revoked when it should have been. That means the IAM team typically owns authentication, conditional access, and joiner-mover-leaver controls; DevSecOps owns repository and pipeline identity, secret scanning, and branch protections; and the application owner owns business approval for who should have access and whether that access remains necessary.

A practical assignment model usually includes:

• Identity governance for account creation, MFA enforcement, and timely offboarding.
• Repository administration for least privilege, protected branches, and audit logging.
• Secret management for removing API keys, tokens, and certificates from code and build systems.
• Detection engineering for alerting on unusual clone volume, token reuse, or access from new geographies.
• Incident ownership for evidence preservation, blast-radius assessment, and post-incident control fixes.

This is where development security and identity security intersect. If a compromised developer account can reach source code, the organisation should treat that access as a privileged path, especially when repositories contain deployment credentials, infrastructure code, or reusable automation tokens. The most resilient programmes pair repository controls with identity proofing, step-up authentication, and short-lived access where practical. Current guidance suggests that logging alone is insufficient unless alerts are tuned to actually surface anomalous access patterns and privilege escalation attempts.

Anthropic’s report on AI-orchestrated cyber espionage reinforces a broader point: identity compromise can become a rapid path to reconnaissance, code theft, and environment pivoting when tooling access is overbroad. These controls tend to break down when developer identities are shared, token lifetimes are long, and repository permissions are inherited loosely across teams because attribution and revocation both become unreliable.

Common Variations and Edge Cases

Tighter access governance often increases developer friction and review overhead, requiring organisations to balance speed of delivery against the cost of stronger control validation.

There is no universal standard for this yet, but current practice is moving toward shared accountability with clear ownership registers. In highly regulated environments, the application owner may carry formal business accountability while IAM and DevSecOps own technical control execution. In smaller engineering teams, one person may wear multiple hats, but the control responsibilities still need to be documented separately so an incident review can identify which safeguard failed.

Edge cases matter. A contractor account used for release engineering may have legitimate repository access without being a “developer” in the strict sense, yet the accountability structure is the same. Likewise, if source code was exfiltrated from a fork, mirror, or CI system rather than the primary repository, the control owner may shift to platform engineering or build operations. Where the stolen code includes secrets, the incident also extends into secrets governance and may require immediate credential rotation rather than only account remediation.

For organisations using agentic tooling, the same logic applies to non-human identities that can read or modify repositories on behalf of humans. If those identities are over-privileged, accountability expands into NHI governance as well as human access control. The practical answer is to assign one owner for access policy, one for repository control, and one for business acceptance of the risk, then test those responsibilities before an incident forces the issue.

Related resources from NHI Mgmt Group

• Who should be accountable when compromised npm packages spread through CI and developer systems?
• Who is accountable when payroll fraud succeeds through a compromised account?
• Who is accountable when a retail customer account is compromised through a partner system?
• Who should be accountable when a compromised developer account can reach cloud infrastructure?