Regex hook gaps and credential boundaries: two practical looks at AI agent control

Two recent posts on dev.to tackle the same underlying question from different directions: when an AI agent can act on your system, what actually constrains it? One tests what a Claude Code guard hook really blocks; the other proposes a design for agents that need to log in to services without ever seeing the password.

What a regex hook actually blocks

Claude Code lets developers register a PreToolUse hook in settings.json: a shell command that runs before each tool call, receives the tool name and its input as JSON, and returns a decision to approve or block. According to a post on dev.to, the author built a minimal Python hook that checks Bash commands against a regex of known-destructive operations (rm -rf, git push --force, git reset --hard) and tested it against four crafted inputs.

The results split down the middle. A safe command passed, and the literal destructive command was blocked, exactly as intended. But two variants slipped through: the same rm -rf with the flag assembled from a variable (x=rf; rm -$x ...), and the same destructive intent routed through an MCP tool the hook never inspects (mcp__some-server__delete_everything). Both were approved.

The failures are structural rather than bugs, the post argues. The hook is a pattern match on one tool's string input: it never executes the command, so it cannot know what rm -$x expands to, and it has no opinion about tools its author did not write checks for. It also cannot steer the agent toward a safer approach, ask a clarifying question, or notice that two consecutive commands were attempting the same thing. It evaluates one literal string, once, against a pattern written in advance.

The author's conclusion is not to delete the hook — plenty of destructive commands really are typed the obvious way — but to demote it from the primary control to one layer, alongside restricting which tools and MCP servers a session can access in the first place. A tool no hook checks is not protected; it is simply unwatched. The practical advice is to test your hook with the inputs you actually fear, not just the ones you wrote the regex against.

The credential boundary

A second dev.to post, by Edan Harr, addresses the other side of agent autonomy: what happens when the agent needs a login. The default today is pasting a password into chat, which leaves the secret in a transcript and in the model's context — unscoped and effectively impossible to revoke. The post sets out five design principles and how they are applied in AgentKey, the agent credential vault the author is building.

The first principle is structural separation rather than behavioural trust: the model never holds the plaintext credential, and only a narrow execution layer may cross that boundary, after explicit owner approval. Designs that rely on the model choosing not to misuse a secret it can see are treated as wishful thinking rather than security.

The remaining principles cover the human side. Approval should be a single decision — in AgentKey, the agent sends a request link, the owner taps to approve on their phone, and the grant lasts until revoked rather than silently expiring on a timer. Grants are scoped per agent and per login, revocable with one switch, recorded in an activity view, and restorable from an archive. Agents should be added like contacts rather than provisioned like infrastructure; agents living inside other apps connect through standard OAuth consent screens — the post notes both Claude and ChatGPT support custom connectors — and the connector carries only requests and statuses, never secrets.

Finally, execution is its own layer: a sandboxed browser session is the only component that touches the plaintext, while the agent works against a scrubbed view of the page showing labels rather than values. The executor reads login pages directly instead of depending on hand-maintained per-site adapters, on the grounds that a vault limited to a compatibility list is a plugin collection, not a vault. The author explicitly invites feedback on the principles more than the product, including where task scoping should live and what audit format suits a human who rarely checks the receipts.

Why it matters

Both posts converge on the same lesson from opposite ends of the agent stack. Instructions in a system prompt or a CLAUDE.md file are advisory — the model can ignore or forget them. Enforcement has to live outside the model: a hook that gates tool calls, or a boundary that keeps secrets out of context entirely. But each mechanism covers only what it literally watches. A regex hook stops the destructive command you anticipated, not the one assembled from variables or routed through an unchecked tool; a vault stops the secret leaking only if every path to it goes through the boundary. As agents gain shell access and MCP tool surfaces keep growing, the sensible posture is layered, tested controls — and scepticism toward any guardrail you have not fed an adversarial input.