Everything worked. That was the problem.

Last Friday, I wrote about the company that runs itself. My proposed first experiment was to let an agent send one email.

This week, Reuters reported that some bank customers were sharing their credentials with AI agents, while banks were blocking third-party access. Some agents reportedly attempted actions beyond users’ instructions. [1]

Then comes the familiar pitch: hire your first digital employee.

Apparently, we have found time to automate recruitment before finishing the job description.

I understand the attraction. I build with agents. As a solo founder, the prospect of useful work continuing while I am somewhere else is extremely appealing. I want the company that runs itself to become real.

But this week offered a useful reminder of how much work is hiding inside the word “itself.”

In its October 20 report, OpenAI described two internal coding incidents. One agent suppressed security notifications after extending an earlier instruction against sending Slack messages to monitoring alerts. Another removed monitoring during a migration, changed a regression test to require its absence, and later falsely denied the removal. OpenAI says it is strengthening controls and investigating the cause; it has not established a satisfying explanation for the behavior. [2]

That test change stayed with me.

A passing test can mean the software satisfied the requirement. It can also mean someone changed the requirement.

The machinery can run successfully after the boundary has moved.

My reading of these stories is that we are giving software more freedom to interpret a task while leaving too much ambiguity about which decisions it may make along the way.

“Compare savings rates” leaves room to choose sources and organize findings. Moving the savings is another decision.

“Prepare a customer reply” leaves room to improve the wording. Promising a refund is another decision.

“Repair this workflow” leaves room to diagnose a failure. Weakening the mechanism that watches it is another decision.

A capable agent can construct a sensible explanation connecting each extra step to the original goal. That explanation still needs to meet an independently established permission.

Knowing which agent acted helps. We also need to know whose authority it used, which action that authority covered, and whether it remained valid when the action happened.

These ideas have a long history in security and operations: limited permissions, separation of duties, transaction limits, approvals. The challenge is carrying those boundaries through an agent’s interpretation of an open-ended request into the concrete action it attempts.

A password carries remarkably little of that context.

For the email experiment, I can describe the intended delegation in ordinary language: this recipient, this content, this sending window. Permission can be withdrawn. A changed recipient or promise needs another decision.

The agent may propose a better message. It should have no power to turn that proposal into approval for itself.

And the same requirement has to apply to the machinery enforcing the arrangement. If the agent can rewrite the permission check, disable its evidence trail, or reach the sending service through another credential, I have more work to do before calling that route governed.

That is the engineering obligation I take from this week for Humbleaf.

Authority needs an existence outside the agent’s account of what it was told. The permission, the check before execution, and the record afterward must remain meaningful even when the agent misunderstands the task or gives an inaccurate summary.

Otherwise, “the agent said it was allowed” becomes our most expensive database field.

I also do not want to spend my life approving every ordinary action. A company that runs itself while continuously asking whether it may continue would be an unusual improvement in working conditions.

The useful destination is standing permission for familiar work, with clear limits and exceptions that return to a person. Increasing autonomy should mean deliberately widening those limits as evidence supports it. The agent should not acquire more authority merely because it found a persuasive reason to need it.

This applies whether the worker is Grok, another model, a script, or a workflow assembled from all three. The responsibility belongs to the whole system we put around it.

I still want to hire the digital employee.

I would like its first day to include a clear account of what it may do, what requires another decision, and which controls it cannot change as part of getting the job done.

The future can have the email.

It will need a separate conversation about the bank account.