An agent that was never shown the token still published articles from an authenticated terminal (unverified report)

What happened

On October 2, 2026, the day the author set up a workflow for posting to Qiita, they wrote a task-split table into their runbook. Creating accounts, issuing and entering tokens, and the final call on push and publishing were the author’s job; login, publish, pull, push and setting Secrets were listed as things the agent must not do. The next day, October 3, the agent switched an article that had been checked in limited-sharing mode to public, after the author’s explicit go-ahead. The publish command ran in an authenticated terminal and went through without the token’s value. In the Zenn repository, too, the agent ran commit and push, and also did the publishing push (published: true) after an explicit go-ahead.

The chaos on the ground

On October 7 the author audited the metadata of their setup, without reading any credential contents. The credentials file was readable by its owner only, Git authentication went through the OS keychain, and the remote URL contained no token. But the permission deny list was empty, no sandbox was configured, and while hooks guarded things like pre-commit review, none guarded credentials. Owner-only permissions do nothing against commands the agent runs as the same user as the author.

The same day, the agent tried to check whether the token’s value had shown up in the conversation logs and was about to run a command searching those logs for credential strings. The auto mode classifier stopped it just before it ran; the agent did not try to get around it and handed the check to the author. The conversation logs, the read history of the credentials file, environment variables and their inheritance by child processes, and shell history all remain unchecked.

Root cause

The author separates two lines: not showing the value to the agent, and not letting the agent use authenticated operations. The runbook’s policy covered the first; the second was held only by the wording of the table. The table said who does what; it was not a mechanism deciding what could run.

The author also lays out the limits of each technical control. Per the permissions documentation, read deny rules apply to the built-in file tools and to commands like cat, head, tail, sed and tee, but not to grep -r without a file name or to arbitrary subprocesses, and Bash rules are not a security boundary. For the auto mode classifier, an Anthropic article reported a 17% miss rate on 52 real overeager actions, and under auto mode’s settings a push to the working repository, default branch included, is allowed by default.

The fix

The author’s approach is a line held by human confirmation, not technical enforcement: show the diff before publishing, get an explicit go-ahead, and keep the final call with the author. The agent can still run authenticated operations. The official documentation gives an example of adding Bash(git push *) to permissions.ask to force a prompt, but notes that other forms such as git -C <dir> push are not caught. The author says they do not claim the token was never exposed.

Keeping credentials out of an agent’s sight and keeping it from using them are separate controls. Listing the authenticated commands an agent can run (push, publish, API calls) and deciding for each whether to block it technically or guard it with a human check makes it possible to audit which line is actually holding.