Who Should Own GitHub, Hosting and API Accounts on an AI Project?

Why Account Ownership Matters on an AI Project

A modern AI application depends on much more than source code.

Production infrastructure can include:

• GitHub
• Cloud hosting
• Databases
• AI APIs
• Domain and DNS
• Email services
• SMS or voice platforms
• Analytics
• Monitoring
• CRM integrations
• Payment systems
• Cloud storage
• Environment secrets

If these assets sit across personal developer accounts, the business can have a working application without full operational control.

Losing access to a domain, production database, deployment settings, API billing, or recovery email can stop the system from operating.

For most custom AI and software projects, the operating model should be simple:

The business owns the production assets, and the technical team receives controlled access.

Who Should Own the GitHub Repository?

Production repositories should normally sit inside a GitHub organisation controlled by the business instead of inside an individual developer's personal account.

GitHub organisations are designed for shared ownership and team access.

They support:

• Organisation roles
• Repository permissions
• Teams
• Outside collaborators
• Different access levels for different contributors

A developer may need Write access.

A technical lead may need Maintain or Admin access.

A contractor can be given access to a specific repository without becoming an owner of the organisation.

For continuity, the organisation should also have more than one trusted owner-level administrator so access does not depend on a single person being available.

The main point is ownership.

A developer can manage the repository without personally owning the business's production source code environment.

Who Should Own the Hosting Account?

The same principle applies to production hosting.

If the application runs on Vercel, AWS, Microsoft Azure, Google Cloud, or another provider, the business should normally control the production account and billing relationship.

That does not prevent the development team from managing deployments.

Modern hosting platforms use role-based permissions so developers can deploy, troubleshoot, configure, or administer projects without controlling every company resource.

For example, a hosting account can separate responsibilities for:

• Ownership
• Development
• Project administration
• Billing
• Viewing
• Deployment

The business should also control its domain registrar and DNS.

Hosting can often be migrated.

Source code can be transferred.

Losing administrative access to a company domain can interrupt the website, email, API endpoints, and customer-facing systems at the same time.

Who Should Own the API Accounts?

Production AI and third-party API accounts should generally be created under the client's business account, business email, and billing method.

The technical team can then be invited into the account or given project-level access.

This model applies to:

• AI model providers
• SMS platforms
• Voice platforms
• Transactional email services
• Mapping services
• Cloud databases
• Monitoring tools
• Payment integrations
• Other paid APIs used by the application

OpenAI's API platform, for example, separates organisation-level access from project-level access.

Projects can have their own:

• Members
• Service accounts
• API keys
• Usage controls
• Project resources

That allows the client to retain ownership while giving developers access to the specific application they are working on.

Do Not Use Shared Personal API Keys as the Ownership Model

An API key is a credential.

It should not become the ownership structure for the project.

A common shortcut is for a developer to create an API account personally and place one key into the production application.

That may work during development, but it creates weak controls around:

• Billing
• Security
• Access removal
• Cost tracking
• Staff changes
• Project transfer
• Business continuity

A better structure is:

1. The business owns the API organisation or account.
2. People receive individual account access.
3. Projects receive dedicated credentials.
4. Applications use service or project credentials.
5. Production credentials stay outside the source code.

Separate credentials also make it easier to track usage, rotate secrets, remove access, and troubleshoot problems.

Avoid Shared Administrator Logins

Another weak pattern is creating one administrator account and sharing its username, password, and multi-factor authentication details across the founder, agency, and developers.

Shared administrator accounts make activity harder to attribute and access harder to remove.

People should normally have named accounts.

Applications should use service accounts or application credentials when the platform supports them.

Permissions should match the person's role instead of giving every contributor full administrative access.

A developer who only needs deployment access should not automatically receive billing, account recovery, DNS, and organisation ownership permissions.

The same principle applies to automated services.

Give each person or system the access required for its job rather than unrestricted access across every production system.

What Should the Client Own?

The agency may administer several of these systems. Administration and ownership are different.

A development partner may configure infrastructure, manage deployments, monitor systems, troubleshoot production issues, or maintain integrations.

The underlying business accounts can still remain under the client's control.

What Access Should the Developer Receive?

Developers still need enough access to work efficiently.

Depending on the project, that can include:

• GitHub Write or Maintain access
• Deployment access
• Development database credentials
• Development API credentials
• Application logs
• Environment configuration
• Testing resources
• Temporary production access for approved troubleshooting

A technical lead may need broader permissions.

The better approach is role-based access tied to responsibility.

When someone changes roles or leaves the project, access should be reviewed and removed where it is no longer required.

Separate Development, Staging and Production

Development and production should not automatically share the same credentials.

A stronger setup separates:

• Development
• Staging
• Production

Each environment can have its own:

• Database
• API project
• API keys
• Service accounts
• Deployment configuration
• Environment variables
• Test data
• Access permissions

This reduces the chance that testing affects live customers or production data.

It also gives the business better cost tracking.

Contractors can work in development or staging without automatically receiving unrestricted production access.

Production access can then be limited to the people who actually need it.

Can the Agency Ever Own the Accounts?

Yes.

There are legitimate situations where an agency owns part of the infrastructure.

For example, an agency may provide a managed service where hosting, monitoring, APIs, infrastructure, and ongoing support are included in a monthly fee.

A prototype may also begin inside an agency sandbox before the client decides to move it into a production environment.

These arrangements can work when they are intentional and documented.

The agreement should explain:

• Who owns the source code
• Who owns the data
• Who owns each production account
• Which assets can be transferred
• Which assets cannot be transferred
• What third-party charges are included
• What remains part of shared agency infrastructure
• What happens when the agreement ends
• How migration or termination will be handled

Problems usually arise when ownership is assumed rather than documented.

Plan the Handoff Before the Project Starts

Account handoff should not begin after the final invoice.

Before production deployment, create a simple account register.

Record:

• Platform
• Account owner
• Billing owner
• Administrative users
• Developer access
• Recovery method
• Renewal details
• Service credentials
• Offboarding process

Then apply a simple continuity test:

If the current developer became unavailable tomorrow, could the business still access the code, production infrastructure, data, billing, and recovery controls and give the project to another qualified team?

If the answer is no, the account structure needs attention before the system becomes more important to daily operations.

The Simple Ownership Rule for AI Projects

A practical ownership model looks like this:

• The client owns production assets.
• The agency receives controlled access.
• Developers use individual accounts.
• Applications use dedicated service credentials.
• Development, staging, and production stay separate where practical.
• At least two trusted people retain recovery-level access to core business systems.
• Access is reviewed when people join, change roles, or leave.
• Production secrets stay outside public repositories.
• Billing remains visible to the business.
• Account ownership and handoff requirements are documented.

Good account ownership makes an AI system easier to operate, maintain, transfer, and expand.

GitHub, hosting, domains, API organisations, production databases, credentials, billing, and recovery access are part of the company's operating infrastructure.

They should be treated that way from the beginning.

Web Inventix AI helps businesses plan and build AI, automation, and custom software systems with clear ownership, access controls, production architecture, and handoff requirements built into the project from the start.

Frequently Asked Questions