The Agent Codes, the Human Being Decides: Where Should Control Sit?

One morning, an AI agent prepares a commit at my request. It has modified the files, run the checks, and is about to record its work in Git, the software that preserves the project's history.

But when it comes to signing the commit, it stops. My GPG key is stored on a YubiKey, a physical key protected by a PIN. Without my intervention, it cannot complete this operation.

At first, the interruption feels inconvenient. Then I see its value: the agent prepares the change, but needs my approval to record it with my signature.

A few commits later, however, the PIN is no longer requested. Entering it once has allowed several signatures.

The checkpoint therefore exists, but its scope depends on configuration.

One signature or several: a deliberate choice

I can require a fresh intervention for every signature, or let the agent continue after an initial authorization.

In the first case, each commit creates a pause. I can examine the changes before letting the agent record them. It is more demanding, and sometimes frankly tedious, but the interruption can be useful.

In the second, the work moves more freely. If I already follow changes as they are produced, returning to the key every time can add friction without improving my control.

Both choices are defensible. What troubles me is believing I approve every commit when my authorization covers several signatures.

And even with systematic intervention, nothing guarantees I actually examine the work. I can enter the PIN or touch the key mechanically. The gesture creates an opportunity to check; it is not the check itself.

The signature makes it possible to verify the use of a key and the integrity of the signed content. It proves neither code review nor the quality of the tests.

I thought I understood the scope of this protection. Another incident showed me its limit.

The agent did not need my key

While two agents were working on the same repository, one recorded its changes directly on main, the branch containing the project's reference version.

The other was still working from my computer on an outdated version. Its work had to be brought up to date, but one question particularly stopped me: how had the first agent created that commit without requesting my YubiKey?

It had taken another path.

Instead of using Git on my computer, it had written directly to the remote repository with the GitHub connector. My local signing configuration did not apply to that operation.

The agent had not forced access to my key. It simply had not needed it.

I had protected signing on my computer, but that protection did not cover every way of changing the project.

That observation changed the question. Choosing how often I wanted to intervene was no longer enough. I also needed to consider where that intervention became necessary.

Letting the agent produce, then deciding on integration

A working branch keeps the agent's changes separate from main. It can experiment, test, and record intermediate steps without immediately changing the reference version.

A pull request then becomes a proposal for integration: it brings together the changes, check results, and discussions needed for review.

This lets me shift my attention. Rather than intervene on every preparatory commit, I can examine the whole change before its integration.

But a pull request alone does not make my approval mandatory. If the repository still permits direct writes to main, that step remains avoidable. And if the agent has permission to merge on its own, it can also cross the boundary I thought I had reserved for myself.

Control therefore depends on the repository's rules and the permissions granted to the agent: mandatory pull requests, required checks, and access to merging.

There is a limit to acknowledge here: if the agent acts with my account and my permissions, the platform does not automatically distinguish its decision from mine. An instruction given to the agent can organize our collaboration, but is not equivalent to a technical restriction.

What I want to keep in my hands

I am not trying to intervene before every operation. The point of an agent is precisely to assign work and let it progress.

However, I want to distinguish what it can prepare on its own from what requires my approval. Physical signing can create that boundary in a local workflow; review and merge rules can place it at repository level.

These two experiences therefore led me to a more precise question:

Is my approval actually necessary to integrate the work, whichever path the agent uses?

My organization and configuration need to answer that question. Otherwise, I risk keeping the feeling of control while leaving another path open.

git config --local gpg.format openpgp
git config --local user.signingkey KEY_FINGERPRINT
git config --local commit.gpgsign true

git verify-commit HEAD

ykman openpgp info

# Verify the PIN for every signature
ykman openpgp access set-signature-policy always

# Verify the PIN once per card session
ykman openpgp access set-signature-policy once

ykman openpgp keys set-touch sig on