Departing Engineer and the Nightly Repository Clones

The pattern is suspicious but not conclusive. 38 clones against a peer baseline of two per week is a strong volume anomaly, and 3.1 GB at 23:00-01:00 from home is unusual. Access to the autonomous-mobility repo outside his scope is the strongest signal because it suggests interest beyond handover. However, a departing engineer doing handover may legitimately clone many repos to document work, and Git clones are normal for firmware teams. The timing could reflect a final push before departure. The key is to test authorization and content: did his manager approve access to the restricted repo, and does the clone include the legacy branch with signing keys? Check Git audit logs for repo names, branch, and whether he cloned the key-containing branch; check endpoint for archive creation, USB, or personal cloud upload; check email for forwarding. Compare with two other departing engineers' handover behavior. The absence of a DLP alert is not exculpatory. Reason from data sensitivity and authorization, not from volume alone.

Respect the works-council agreement before covert monitoring. The SOC can preserve existing logs and review them, but covert endpoint monitoring or email inspection may require consultation. Engage HR, legal, and the works council early; document the legal basis and scope. Immediate actions: preserve Git audit logs, endpoint telemetry, badge and VPN logs, and the repository's key-branch access records; do not delete or modify his accounts yet. Ask the manager for a specific handover plan and authorized repo list, in writing. If the restricted repo is unauthorized, revoke that access immediately and rotate any signing keys in the legacy branch. Do not confront the employee alone or accuse him; HR should lead any interview. Consider whether the company needs to escort him on the last day or revoke access at the handover cutoff. If evidence shows exfiltration of keys or source code, escalate to legal for preservation and possible law enforcement. The reasoning is to avoid both a privacy violation and a rushed accusation that destroys evidence.

Improve three areas. First, detection: add an ABA rule for departing employees with notice date, comparing repo clones and data volume to a handover baseline, and a specific rule for access to repositories outside the employee's team. Second, access governance: require manager re-certification of repository access within 24 hours of notice, and auto-expire restricted repo access unless the manager approves a handover exception. Third, data protection: find and rotate signing keys in legacy branches, move them to a secrets manager, and block clones of key-bearing branches without approval. Add DLP coverage for Git over HTTPS and SSH where feasible. Train managers on handover scope so legitimate cloning is documented in advance. Review the works-council process for insider cases and create a playbook with HR and legal. Measure the change by replaying the case: would the new rule have alerted earlier without flooding on normal handovers? If the handover baseline is too broad, narrow it by repo sensitivity.