Acting as the User: Authentication, Identity, and Trust

Part 3 of 9 — the single property that separates a legitimate operator from a bot, and how to get it right.

Whose hands are on the levers?

When the operator sends a message to a buyer, eBay records who sent it. The answer to "who" is the most consequential design decision in this whole pattern, and it has only one acceptable answer for the setup we are describing:

The operator acts as the user — using the user's own authenticated, consented access to a system they already have an account on. It is not a third-party bot impersonating anyone, and it is not a shared service account pretending to be a person.

This is not a legal footnote; it is the foundation. "An automated agent running on my workstation, signed in as me, doing things I am allowed to do" is a fundamentally different — and defensible — proposition from "a robot that logged into someone's account." The first is you, working faster. The second is trouble.

What "as the user" means concretely

The user has a real account on the external system and the right to do the actions in question (sell, message buyers, issue refunds).
The user consents to the tools acting on their behalf, through the system's sanctioned mechanism — typically an OAuth authorization where the user logs in and grants specific scopes.
The access is scoped. The token grants only the permissions the tools actually need, not blanket account control.
The access is revocable. The user can withdraw it at any time from the provider's side, independent of the workstation.
Actions are attributable. The provider can see the work was done via an authorized integration tied to that user.

The authentication pattern

For most modern systems the mechanism is OAuth 2.0 with user authorization. The shape, regardless of provider:

You register an application with the provider once. This identifies your tool belt as a known integration and yields a client ID/secret.
The user runs a one-time … auth login command. A browser opens, the user logs into their own account and approves the requested scopes.
The provider returns tokens — a short-lived access token and a longer-lived refresh token.
The tools store these securely and use them on every call. When the access token expires, the refresh token silently mints a new one.

Build note — token storage. Tokens are the keys to the user's account; treat them like passwords. Store them in the OS keychain (macOS Keychain, Windows Credential Manager, the Secret Service / libsecret on Linux) via a library like Python's keyring, not in a plaintext .env committed to a repo and never in the agent's prompt or shell history. A tool reads the token at the moment of the call and uses it; the secret never enters the conversation the agent sees.

Why the agent must never see the secret

A coding agent keeps a transcript. Anything in its context can end up in logs, in a summary, or — if you use a hosted agent — on someone else's infrastructure. So the rule is firm:

Credentials are read by tools, from a secure store, at the moment of use. They are never passed as arguments the agent constructs, never printed, never placed in soul.md.

The agent runs ebay-refund --order 4471 --amount 18.00. It has no idea what the OAuth token is, and that is exactly right. The tool fetches the token from the keychain internally. This is also why CLI tools beat raw API access on security (Part 2): the wrapper is what keeps the secret out of the model's sight.

The Terms-of-Service question

Acting as the user does not automatically make every action permitted. Many platforms have specific rules about automation, rate limits, and what their API may be used for. Before you point an operator at a real system:

Use the sanctioned API. Public, documented APIs with an OAuth flow are an invitation to integrate. Scraping the website or driving a hidden internal endpoint is not, and usually violates the ToS.
Respect rate limits and automation clauses. Some platforms restrict bulk messaging or automated pricing. Read the developer agreement; build the limits into your tools.
Keep a human in the loop for consequential writes. Beyond safety, this keeps the operation recognizably operated by a person, which is both the ethical and the compliant posture.

The trust test. A good gut-check before adding any capability: "If the provider's trust & safety team watched a recording of this, would they see a legitimate account holder doing permitted work efficiently — or a bot?" If you can't answer "the former" with a straight face, stop and redesign.

Identity is also how skills stay safe to share

This matters later (Part 6). When you share a tool or a skill with a teammate, you are sharing the procedure, never the credential. Your colleague installs the same tools and runs auth login with their own account. The shared artifact is the know-how; the identity stays personal and local. That separation is what lets a team build a common operator library without anyone ever handling anyone else's keys.

With identity settled, we can finally build something. Part 4 dissects a single tool end to end.