I help run IT and administration at a small 10-person company. Two of us provide most of the technical support, and we use a group of Claude-based agents for different projects and processes. One agent, called cladmin, handles IT support, ticket management, repetitive-task tools, procedures, and guidance for reporting Microsoft 365 issues. The agents normally commit their documents, code, and other work to private GitHub repositories as both a backup and a history of changes.
We have hesitated to use GitHub for cladmin because its files include a ticket list containing real names and email addresses, including those of a former employee; an inventory of domains spread across several registrar accounts; and a complete list of shared mailboxes and distribution lists in our Microsoft 365 tenant. There are no passwords, API keys, or other credentials stored there.
Would keeping this information in a private repository be an acceptable practice, or should it be stored and managed somewhere else? What security, privacy, access, backup, and compliance issues should we consider?
3 Answers
Before automating more of this, get an experienced administrator or managed service provider to review the setup. A small company can still suffer a serious outage if the agents change the wrong setting, expose an inventory, or make an incorrect assumption about Microsoft 365.
Use the agents for research, drafts, repetitive work, and documentation, but require human approval for access changes, account deletion, mail-flow changes, security settings, and anything that affects production. Test restores, keep an independent backup, and make sure at least two trusted people can take over if the main operator is unavailable.
The bigger question is whether GitHub is the right system of record. Git is excellent for procedures, scripts, configuration examples, and change history. It is much less suitable as a ticketing database or an inventory system containing personal data and tenant-wide address lists.
A practical split would be: keep sanitized runbooks, automation code, and documentation in the repository; keep active tickets and personal information in a proper help-desk or business database; and keep domain, mailbox, and asset inventories in a restricted management system. Link the documentation to those systems without copying more data than necessary. If you must store exports in Git, encrypt them before committing and document who is allowed to decrypt them.
A private repository is not automatically a bad place for this, but you should treat it as sensitive company data rather than ordinary project files. Check exactly who can access the organization and repository, require strong authentication and MFA, limit permissions, review audit logs, and make sure former staff cannot access it. You also need a recovery plan so the company is not dependent on one person's account.
I would avoid committing raw names and email addresses where they are not necessary. Keep the operational documentation and sanitized templates in GitHub, while storing the live ticket export and directory inventories in a system designed for that information. If you do use Git, consider a private self-hosted option or encrypted files, and remember that deleting a file in a later commit does not remove it from the repository history.
Also confirm whether your repository provider, AI tools, and backups are covered by your company's privacy and contractual requirements. A private repository protects against casual public exposure, but it does not eliminate insider risk, account compromise, provider access, or accidental sharing.
The fact that no credentials are stored is good, but the data is still sensitive. A complete map of domains, mailboxes, staff identities, and tenant structure can help an attacker, so it deserves controls similar to other internal administrative records.