DEV Community: Octuo team

Let an agent sign in for you without showing the model your password

Aline Mercer — Sat, 17 Oct 2026 09:26:22 +0000

You are halfway through a task with an agent. It has found the settings page and filled in most of the form, and then it stops: "To continue, please paste your password here." Or it needs an API key for the service it is about to call, and the chat box is right there.

It feels harmless because the conversation feels private. But a chat is not a safe.

Why the chat box is the wrong place

Anything you type into a prompt becomes part of the model's context. Depending on the tool, it may be kept in history, written to logs, sent to a hosted model or summarized into memory that later conversations read. You cannot see or reliably delete all of those copies.

The same goes for instruction files. Files such as CLAUDE.md or AGENTS.md exist so the model reads them on every run. That makes them a good home for project conventions and a bad home for a token. Treat them as visible to the model, and often to everyone with access to the repository.

The goal is simple to state: the agent can use a credential, but the raw value never enters the text the model reads or writes.

Use a store the tool calls for the model

The pattern that works is a credential store or vault that sits outside the conversation. The model asks for an action, such as "sign in to the billing portal" or "call the API with the deploy token", and the tool fetches the secret and uses it directly. The model sees a reference or a result, never the value.

Your operating system's keychain is the simplest version of this; a dedicated secrets vault adds encryption, access rules and a usage history. Either way, check one thing: when the agent uses the secret, does the value show up in the transcript? If it does, the store is decoration.

Give the agent less than you have

Scope tokens. Create a token for the one job: read-only if reading is enough, one repository, one project. Do not reuse a key that can do everything.
Expire them. A short lifetime turns a leak into a small incident. Set the expiry when you create the token, not later.
Prefer OAuth and app passwords over master passwords. Delegated access can be limited and revoked without changing the password you use everywhere else. A master password should never be something an agent holds.
Keep 2FA and payments in human hands. The second factor is where a person confirms intent. Let the agent get you to that screen; you approve the code, the purchase or the transfer yourself.

Log every use, and read the log

A credential an agent can use should leave a trace each time it is used: which secret, when, and for which task. Many services also keep their own sign-in and API activity pages. Set a recurring reminder to skim both. You are looking for uses you do not recognize, at times you were not working, against services you did not ask about.

After a paste accident, rotate

If a secret did land in a chat, a log or a committed file, assume it is exposed. Rotate it at the source, revoke the old value, then clean up the copies you can find. Deleting the message is fine, but it does not replace rotation.

Risk and the safer habit

Risk	Safer habit
Pasting a password or key into the chat	Keep it in a vault or keychain the tool reads on the model's behalf
Tokens in CLAUDE.md, AGENTS.md or other instruction files	Refer to a named secret; never write the value
One broad key reused for everything	Scoped, per-task tokens with an expiry date
The agent holds your master password	OAuth or app-specific passwords you can revoke
The agent completes 2FA or a payment alone	You confirm the code, purchase or transfer yourself
No record of what the agent did with access	A usage log per secret, reviewed on a schedule
A secret leaked into a transcript	Rotate at the source first, then clean up

Before you let an agent sign in through a browser

Browser sign-in is where agents become most useful for website chores. Before you grant it, check:

[ ] The credential comes from a store, not from the chat or a file the model reads.
[ ] The account has the least access the task needs; a separate, limited account is better where the site allows it.
[ ] 2FA stays on, and the second factor reaches you, not the agent.
[ ] Payments, account deletion and security settings need your confirmation.
[ ] You can see which sites the agent signed in to, and when.
[ ] You know how to revoke the session or token in one step.
[ ] Saved browser sessions are cleared or expire when the task is done.

None of this needs special tooling to start. Move the next secret out of the prompt, shorten the next token's life, and keep the last click on anything irreversible for yourself.

This post comes from the Octuo team at Tutuo, Inc. More of our notes on handing work to agents are on our blog.

Drafted with AI assistance and reviewed before publishing.

The handoff brief: what to write before a coding agent starts

Aline Mercer — Sat, 17 Oct 2026 08:51:11 +0000

Most agent runs that go sideways don't fail at the code. They fail at the handoff. The task lived in someone's head and the prompt carried only half of it. The diff that comes back answers a slightly different question than the one we meant to ask. Reviewing it then means working backwards from the output to the intent, and that is the slow direction.

So before we give any non-trivial task to Codex or Claude Code, we write a short handoff brief. Review then becomes a comparison: did the run do what the brief said, and nothing else?

What goes in a brief

Goal: the outcome in one or two sentences, not the method.
Scope: what the agent may change, as paths or modules.
Off limits: files and behaviour it must not touch, even if it thinks it should.
Checks: the exact commands that prove the change works.
Done: the observable state that ends the task.
Report back: what the summary must contain.
Escalate, don't guess: decisions that belong to a human.

The last item does the most work. When an agent hits an ambiguity, it will usually resolve it somehow. If you name the ambiguities up front, a silent guess becomes a question in the report.

The template

## Goal
<What should be true when this is done.>

## Scope
May change:
- <path or module>

Off limits (do not edit, even to "fix" something):
- <generated code, migrations, lockfiles, CI config>
- <public interfaces other code depends on>

## Context
- <Why this change; constraints the code doesn't show>
- <Link to the issue or prior decision>

## How to check
- Run: <test command>
- Run: <lint / type-check command>
- Expected: all pass, no tests skipped or deleted

## Done means
- <Observable condition>

## Report back
- Files changed, one line on why for each
- Commands run and their results
- Anything noticed but not changed
- Every assumption made

## Escalate instead of guessing
- <Behaviour changes visible to callers or users>
- <New dependencies, secrets or credentials>
- <Checks that cannot pass without touching an off-limits path>

Keep it short. Codex's docs on managing usage advise controlling the size of prompts and reducing the size of AGENTS.md. The same logic holds for readability, because a brief that restates the codebase gets skimmed. Durable project rules belong in the instruction file the tool already reads (AGENTS.md, CLAUDE.md), and the brief covers only this task. Claude Code's guidance to use /clear when starting a new task fits well here: clear the context, then paste the brief.

A vague brief and a better one

The task: a small internal service still calls a deprecated fetchLegacy method on its HTTP client wrapper.

The vague version:

Replace the deprecated fetchLegacy calls with the new client API and make sure everything still works.

That brief leaves four questions open:

Which files count?
Must the retry behaviour be kept?
What does "everything" mean?
What happens to call sites that pass options the new API lacks?

The agent will answer all four. We just won't know how until we read the diff.

The better version:

Goal: no calls to fetchLegacy remain in src/; behaviour for callers is unchanged.
Scope: src/clients/ and src/handlers/. Off limits: src/generated/, the dependency manifest and lockfile, migrations/.
Check: unit tests and type-checker pass, with no tests skipped or deleted.
Done: a search for fetchLegacy in src/ finds only its definition, which stays for a follow-up.
Report: each call site changed, and how retries are handled now.
Escalate: any call site relying on an option the new API lacks. Leave it unchanged and list it.

It's the same task, but now the reviewer knows what a correct diff looks like before opening it.

When the run comes back

Diff first, summary second. The summary is an account of the work; the diff is the work. Check the file list against Scope and Off limits.
Rerun the checks yourself, using the commands from the brief, in a clean state. "Tests pass" in a report is a claim, not evidence.
Look for silent scope creep: reformatted files, renamed helpers, a nearby cleanup, a loosened assertion, a new dependency. Each may be fine. None should be a surprise.
Answer the escalations and write the answers down.
Record decisions in the brief, the commit message or the PR description, so the next brief starts from there.

Where context gets lost between tools

The weak point is rarely inside one run. It sits between runs:

Reasoning from a planning chat never reaches the agent.
An escalation gets answered in one terminal and then forgotten.
A follow-up starts in another tool without any of the earlier decisions.

Each tool keeps its own session history. A brief kept in a file and updated with what came back is the one thing that carries across tools. Treat it like code: version it, review it and reuse it.

This post comes from the Octuo team at Tutuo, Inc. More of our notes on running coding agents are on our blog.

Drafted with AI assistance; the tool behaviour mentioned was checked against the Codex and Claude Code documentation before publishing.