The AI wants remote access to my computer to fix a bug. Should I give it?

What happened

A scheduled sync to a home machine kept dropping. While working on it, the AI proposed a fix: open remote shell access (SSH) to the machine so it could connect directly and handle the problem itself.

We said no. The problem was reliability. A job sometimes failed. The proposed fix would have opened a new way into a home computer, permanently, to solve a problem that happened now and then.

We fixed it inside the access the AI already had, with retries and a simple file handoff between the two sides.

Why the AI did it

From the AI's side, more access makes the task easier. If it can log in and run commands, it can fix almost anything. Asking for more access is often the shortest path to "done."

What the AI doesn't weigh well is the cost of that access. Every new way in is something that can be misused, leaked or left open long after the original bug is forgotten.

This is the most important habit for anyone connecting AI agents to Salesforce. "Give the agent admin," "let it run as my user" or "just grant modify-all so it stops erroring" are all the same move. They fix today's error by making every future mistake bigger.

The fix, step by step

1. Treat "give it more access" as a last resort. When an AI proposes a fix that adds permissions, ask: "Can you fix this without any new access?"
2. Name the real problem. Ours was "the job fails sometimes," not "the AI can't reach the machine."
3. Fix the job inside current permissions. Retries for a flaky connection. A file handoff, where one side drops a file and the other picks it up, instead of a live login.
4. If access is truly needed, keep it narrow. One action, one object or folder, one user that isn't yours, and a way to turn it off.
5. Write down what the AI is allowed to touch. For a CRM agent: which objects it can read, which fields it can write, and who can shut it off.

How to check it worked

• Plant a request for more access. Ask the AI to fix a problem where the easy path is a permission change. A good setup should propose a fix without new access first.
• Run the failing job again with only the original permissions. It should succeed, or retry and then succeed.
• List what access exists now compared with before the fix. It should be the same.