Which accounts are reasonable to connect on the first day, and which should stay human-only?

On the first day, connect three things: one folder or one git branch that contains no secrets and that you will review before anything merges; a browser profile with no saved logins, for public pages; and a local folder where the agent writes drafts you paste yourself. Leave human-only: email, the password manager, banking and billing, the domain registrar, social accounts that can post, the mailbox that receives password resets, and any admin or calendar connection that can invite or disable other people. If you cannot tell whether a connect button does one of those, do not press it.

The first day is when the product wants every logo on one screen. The logos are not the same kind of access. A diff you can read is not a mailbox.

The three connections that are enough

The folder or the branch is the one that earns its keep. Pick a repo that is not production credentials, not your password vault export, not a dump of customer mail. Give the agent that tree, on a branch, and read the diff before you merge. If the tool offers “commit to the default branch,” turn that off or do not use that tool yet. First day means you can throw the branch away. I started with a scratch repo I had made for the experiment, not the repo that deploys the site.

The browser profile is for pages anyone could open. No cookies you care about, no saved passwords, not your daily Chrome profile. Public docs, a status page, a README on the web. If the task needs you to be logged in, it is not a first-day task. Copy the paragraph into the prompt instead. A logged-in session is an account, even when the settings screen calls it a browser.

The draft folder is how mail gets written without mail access. The agent saves a file. You paste it into a client you are logged into as yourself. There is no send tool. This is slower than “connect Gmail.” Slow is the point on day one. You are learning what the agent does with text, not what it does with your sent folder.

What stays human-only

Email stays human. Not a narrower version you hope is read-only, unless you have tested that it cannot send and it cannot see the rest of the mailbox. The real inbox includes password resets and private threads. I do not connect it while I am still finding out whether the agent treats “reply” as permission to finish the send.

The password manager stays human. The agent does not need your vault to draft a paragraph or edit a branch. The moment it can open the vault, every page it reads is a place a secret might be asked for. You type the rare login yourself. Day one is the wrong day to discover the vault tool works.

Money stays human. Bank, card, ad accounts, cloud billing, app-store payouts. An agent that can “check the invoice” on those sites can also click the thing next to the invoice. There is no diff. There is a charge or a changed card. I look at those numbers myself.

The registrar and DNS stay human. A wrong record is an outage, and a compromised registrar is the account that can move the domain. Nothing an agent does on the first day requires the ability to edit an A record. If a tutorial says to connect it so the agent can “verify the domain,” verify it yourself.

Social accounts that can post stay human. A draft of a post in the local folder is fine. The account that publishes is not. The failure looks like a slightly off sentence that already went out, and you hear about it from someone else.

The mailbox that receives password resets stays human even if you talked yourself into a separate “agent inbox.” If resets for your real life arrive there, the agent that can read it can see the reset. Use a mailbox that has never been the recovery address for anything, if you ever create one at all. Do not do that on day one.

Admin consoles, work SSO, and calendar connections that can invite other people stay human. Inviting, disabling, and changing a role are actions other people feel. If the permission screen does not say read-only in words you understand, assume it can invite. I would rather copy today’s agenda into the prompt than learn the invite behavior from a meeting request a colleague received.

The bundle I almost approved

The onboarding screen offered GitHub, Gmail, and a password manager as the recommended set, one button each, described as “so the agent can work like you do.” I connected GitHub only, on the scratch repo, and stopped. I have watched the other path. Someone connects all three because each toggle looks like a feature. The agent opens a reasonable pull request, which feels like proof the bundle was fine, and the Gmail grant sits there unused until a later task says “email the summary.” Unused is not safe. It is loaded.

The GitHub connection was reviewable. I could see the files. Gmail and the vault do not produce a diff I can skim in the same way. A sent message is already sent. A vault read may only show up as text inside a log I was not planning to read. First-day access should be the kind you can audit by looking at one branch. If you cannot picture the artifact you will check tonight, do not connect it this morning.

Read-only is a claim you test

“Read-only” on a button is not a category. It is a sentence the vendor wrote. On day one I do not have time to learn each product’s real scopes, so I do not accept the claim. The test, when I am ready on a later day, is specific. For mail: ask it to send a message to me and confirm nothing arrives, then revoke anything that arrived. For a repo: confirm the token cannot push to the default branch. For a browser: open the profile and confirm the password list is empty and I am not signed into the sites I use.

Until those tests exist, the thing is human-only. I will not run the tests on the first afternoon, because the tests require me to understand what failure looks like. The first day is for one branch and a draft file. That is enough to learn whether the agent follows a short instruction. It is not enough to supervise a mailbox.

What I would add on day two, and what I still would not

Day two, if the branch workflow was boring in a good way, I might add a second repo of the same kind, or a docs site via the logged-out browser. I might paste a calendar day into the prompt. I do not add the calendar account yet. Pasting is the same information without the invite button.

I still would not add email, the vault, billing, DNS, or social publish. Those are not a maturity ladder you climb because the branch went well. They are different actions. A model that edits files carefully can still treat “send” as the end of a sentence. Skill on a diff does not transfer to a payment page.

If a task on day two truly cannot be done without one of the human-only accounts, the task waits. I do that step myself. The agent drafts the words in the folder. Connecting the account “so we can finish” is how day one becomes every account you own. The task was not that urgent.

A revoke path before a new logo

Before I connect anything beyond the three, I want to know where the grant lives and how I remove it. GitHub tokens, the mail provider’s security page, the password manager’s authorized apps, the browser profile I can delete as a folder. If I cannot find the revoke control in under a minute, I am not ready to grant it. First-day tools are ones I can throw away: delete the branch, delete the browser profile, delete the draft folder.

I write down what I connected. A note with three lines, not a spreadsheet. When something odd happens later, that note is the list I disconnect from, and it is short because I refused the bundle.

The first day, on one list

Connect a reviewable branch or folder with no secrets, a browser with no logins, and a draft folder you send from yourself. Do not connect email, the password manager, money, DNS, social publish, reset mail, or any admin tool that can invite or lock people out. Add nothing else until you can name the artifact you will check and the button that revokes the grant. The rest of the onboarding screen can wait. You can still get work done. A first day that ends with one branch you understand is a better start than a tray of logos you have not tested.