Answer
Do you need production access?
No. The free first week has no production writes. Week 1 uses a branch or fork and test keys. In a paid week, each production change needs written approval for that specific action.
The default access
The default is write access to branches only, with your main branch protected. I do not need admin rights on a repository, a cloud account or an organization.
The default environment is a test or staging environment with test data. I do not need production data.
Read-only access is the default for anything outside the repository, such as logs, dashboards or billing exports.
Each Statement of Work lists every access I need, the access level, who grants it and when it ends. I use a named personal account for each system and never a shared login.
When production changes
In a paid week, a production write needs written approval from your decision maker for that specific action.
A production write includes a deploy, a database migration, a change to production data and a change to production configuration.
Each approval names the action, the time window and the rollback step. I record each approved action in the weekly report with its result.
If an approved action goes wrong, I stop, roll back where the approval allows it and tell you in writing at once.
Secrets and removal
You share secrets only through your secret manager or a one-time encrypted link that expires. Secrets never go in email, chat, issues, pull requests, code, commit history or AI prompts.
I ask for test keys with spend caps where the provider supports them. I store secrets only in an encrypted password manager or local environment files that git ignores.
If I find that I have more access than the Statement of Work lists, I tell you in writing and ask you to reduce it. You can remove any of my access at any time, with no notice.