I help run IT and administration for a small 10-person company. Two of us handle most technical issues, and we also use a group of Claude-based agents for separate projects and processes. Each project agent normally commits its documents, code, and work to a private GitHub repository so we have backups and a history of changes.
Our IT support agent manages tickets, documents procedures, creates tools for repetitive tasks, and helps prepare reports for Microsoft. Its repository would potentially contain real names and email addresses, including information about a former employee, a list of our domains across several registrar accounts, and the addresses of shared mailboxes and distribution lists in our Microsoft 365 tenant. It would not contain passwords, API keys, or other credentials.
Is keeping this information in a private company-owned GitHub repository a reasonable practice, or should we use a different system or scrub the sensitive details first? What security, access-control, backup, compliance, and continuity issues should we consider?
3 Answers
An AI agent should not be the final authority for IT changes or incident handling. Have a person review its recommendations and commits, especially anything involving Microsoft 365, domains, access rights, or employee records. Start with a small sanitized test repository, define exactly what the agent may read and write, and review its activity regularly.
It would also be worth having an experienced IT consultant review the setup. A small company can still have obligations around privacy, employee records, and security incidents, and an outside review may reveal risks that are easy to miss when the system has grown organically.
A private repository can be reasonable, but “private” does not automatically mean appropriate for every kind of data. Treat the ticket system and infrastructure inventory as business-sensitive information. Remove or pseudonymize names and email addresses where they are not needed, and avoid storing full tenant exports or other unnecessary personal data. Keep credentials, recovery codes, tokens, and secrets in a proper password or secrets manager, never in Git history.
Before adopting it, verify who has access to the organization and repository, enable strong MFA, use least-privilege permissions, review audit logs, configure retention and deletion rules, and make sure backups are independent of the repository itself. Also confirm that the service and your company policies permit this type of personal and operational data. A dedicated ticketing or documentation platform may provide better access controls and retention features than Git for ordinary support records.
The biggest practical issue is not just confidentiality; it is continuity. Decide who can access the repository if the usual administrator is unavailable, how access is recovered, and how a new employee or contractor would take over. Use a company-owned organization rather than an individual account, document the owners and recovery process, and arrange regular exports or backups that do not depend on one provider.
I would separate the data as well: keep source code and automation in version control, but keep live tickets and detailed employee information in a ticketing system or restricted knowledge base. The repository can contain sanitized procedures, templates, and references to records without becoming a complete directory of your people and systems.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures