Give agents a permission slip, not your password
The safe way to let an agent act is a narrow permission for one job that you can take back at any time.
Give the agent the one thing it needs to do, not the key that does everything.
A password is too much to hand over
An API key (the password one piece of software uses to log in to another) can end up in a browser, a background job or a setup file. Once there, it can outlive the task and travel places it was never meant to go. The better option is a narrow permission that says which action, for whom, how much and for how long, for example “may read this one calendar, for the next hour.” For a client’s connected services, Marketplace manages the connections, the keys, which agent may use what, and a log of every use. The real key stays in a safe place on the server. The agent only gets a short-lived, single-use way to ask for the action it’s allowed.
The same rule on your own computer
The same thinking applies when an agent works on someone’s own machine: approved folders only, checked tools, a pairing step, and running commands switched off unless someone turns them on. Access becomes a clear decision, not an accident of where the agent happens to run. Rules & Approvals can judge what an agent wants to do, but the tool doing the work still has to obey the answer. A rule that nothing enforces is paperwork, not protection.
Easy to take back, easy to check
A useful permission can be narrowed, can expire, can be taken back, and leaves a trail. Some actions also can’t safely run twice, like a payment or a sent email. If the request times out, you need a reliable way to find out whether it went through, rather than guessing and trying again. For one person these are good habits. For a company they are must-haves before launch, and they come as a set: separate permissions, a known person behind each operator account, rules that are actually enforced, a record of events, and a way to recover.