Don't Hand Your Passwords to AI Agents: Security Practices for Credential Separation

When an AI agent fills out most of a settings page for you and then stops with "please paste your password here," or when it needs an API key for some service and the chat box is right there—many people just paste it. It feels harmless because the conversation seems private. But a chat box is not a safe. According to a technical blog post by the Octuo team at Tutuo, this kind of casual pasting is becoming the most overlooked security gap as AI agents spread.

Why the Chat Box Is the Worst Place to Store Credentials

Anything you type into a prompt becomes part of the model's context. Depending on the tool, it may be retained in history, written to logs, sent to the hosted model, or summarized into a memory that future conversations read. You can't see these copies, and you can't reliably delete them.

Instruction files carry the same risk. Files like CLAUDE.md or AGENTS.md exist precisely so the model reads them on every run. That makes them a great place for project conventions and a terrible place for tokens. The article's rule of thumb is simple: treat these files as visible to the model and often visible to everyone with access to the repository.

Octuo sums up the goal in one sentence: the agent can use credentials, but the raw value must never enter text that the model reads or writes. This isn't about giving up the agent's automation; it's about isolating credentials from the conversation context at the architectural level.

Model context is the full set of text an AI agent can "see" while working on a task, including the system prompt, user input, tool results, and conversation history. Once a credential enters this set, it may be written to the provider's logs, used for model fine-tuning (depending on the terms of service), compressed into long-term memory via summarization, or even coaxed out to a third party through a prompt injection attack. What's trickier is that context travels across multiple servers as the conversation progresses; users can neither audit the number of copies nor guarantee that deletions take effect in every storage location. This is the technical root of "a chat box is not a safe": it isn't a storage medium but a data pipeline that leaves multiple traces.

Credential Vaults: Let Tools Fetch Secrets for the Model

The workable pattern is to use a credential vault or store that sits outside the conversation. The model issues an action request, such as "log in to the billing portal" or "call the API with the deployment token," and the tool fetches the secret and uses it directly. The model sees a reference or a result, never the value itself.

The operating system keychain is the simplest version of this idea; a dedicated secrets vault adds encryption, access rules, and usage history. The article flags a key verification point: when the agent uses a secret, does the value show up in the conversation log? If it does, the vault is just decoration.

Every team should actually test this before deploying rather than assuming the tool is secure by default.

The OS keychain (Keychain/Credential Manager) is the built-in encrypted credential store on macOS, Windows, and Linux desktops. It unlocks when the user logs in, and applications read entries through controlled APIs without exposing plaintext. It's a good quick start for individual developers, but its limits are that it's usually tied to a single user session and struggles to support team sharing, fine-grained access control, and cross-machine auditing. A dedicated secrets vault (such as HashiCorp Vault or AWS Secrets Manager) adds dynamic credential issuance, short-lived leases, a policy engine, and a complete audit trail on top, so each agent request is temporarily issued or brokered by the vault according to policy and then reclaimed. Which one you choose depends on scale and compliance requirements, but both share the same bottom line: the secret value is visible only inside the tool process and never flows back into the model context.

Least Privilege: Always Give the Agent Less Than You Have

The article lays out four concrete principles:

Limit the token's scope. Create a token for a single task—read-only if reading is enough, scoped to one repository or one project. Don't reuse a key that can do everything.

Set an expiration time. A short lifetime turns a leak into a minor incident. Set the expiration when you create the token, not after the fact.

Prefer OAuth and app-specific passwords over your master password. Delegated access can be limited and revoked without changing the password you use everywhere else. The master password should never be held by an agent.

Keep 2FA and payments in human hands. The second factor is where intent gets confirmed. Let the agent take you to the page, and approve the verification code, purchase, or transfer yourself.

The common logic behind these four principles is to design "what it can do" and "how much damage it can cause" separately, so that every authorization is revocable and traceable.

OAuth is an authorization framework that lets users grant an app limited access to specific resources without revealing their master password to a third party. Its core is the "token" rather than the "password": tokens can be scoped, given an expiration, and revoked by the user at the authorization provider at any time, without affecting the master password or other authorized apps. An app-specific password is an alternative offered by some services (such as email and code hosting platforms), generating a one-time password for each app that is independent of the master password so that revoking just that password is enough after a leak. The shared value of both is revocability—once a master password leaks, the impact covers every use of that account, and changing it often affects everything at once; a delegated token leak can be precisely isolated and quickly contained.

Audit Logs: Every Use Should Leave a Trace

Credentials an agent can use should leave a record each time they're used: which secret, when, and for which task. Many services also keep their own login and API activity pages. The article recommends setting periodic reminders to review both records, looking especially for usage you don't recognize, times when you weren't working, and services you never requested.

Credential authorization without logs means giving up your only chance to discover anomalies after the fact.

After a Pasting Incident: Rotate First, Clean Up Second

If a secret does land in a chat, a log, or a committed file, assume it has leaked. The correct order is: rotate at the source, revoke the old value, then clean up whatever copies you can find. Deleting the message is fine, but it doesn't replace rotation. This order is easy to get backwards—many people's first instinct is to delete the record and forget that the old value is still valid.

Credential rotation is the process of generating a new value at the source and invalidating the old one; it's the only thing in leak response that can actually cut off an attacker's access. By contrast, "cleaning up copies" only reduces exposure and cannot reclaim content that has already been read or copied. In practice, rotation should follow "create before you destroy": create the new credential and confirm that the services depending on it are running normally, then revoke the old value to avoid service disruption. For scenarios where you can't rotate immediately (such as a key hardcoded in multiple systems), you should at least shorten its validity period and expedite a scheduled fix. Automated rotation (triggered periodically by a vault or key management service) significantly reduces the risk of human oversight and is a common requirement in audit compliance.

A Checklist Before Letting an Agent Log In to a Browser

Browser login is the most useful scenario when an agent handles website chores. Before authorizing, the article recommends checking each item: the credential comes from a vault rather than a chat or a model-readable file; the account has only the minimum permissions needed for the task, ideally using a separate restricted account if the site allows it; 2FA is on and the second factor goes to you, not the agent; payments, account deletion, and security settings require your confirmation; you can see which sites the agent logged into and when; you know how to revoke the session or token in one step; and saved browser sessions are cleared or expired when the task ends.

The article emphasizes that all of this can start without any special tools: move the next secret out of the prompt, shorten the life of the next token, and keep the final click on irreversible operations for yourself. For teams handing more and more work to AI agents, this may be the security habit with the highest return on investment.

---

This article is compiled and adapted from a technical blog post by the Octuo team at Tutuo.