Your Agent Needs Its Own Login

A model running under a person's credentials leaves the connected system unable to distinguish what the agent did from what the person did.

When the agent writes a database row using my account, the database sees my account. An application log may identify the agent's run, but the credential itself doesn't. Revoking it may also cut me off when I still need to investigate.

On Scout, my product-feedback platform, an agent gets its own access grant through a separate approval step. IMO, that separate login is the whole point. An authorization audit found that the tools exposed to the agent had no operation for writing campaign data.

A prompt saying “don't write campaigns” would still leave a write tool available if the application exposed one. Removing the operation closed that path regardless of what the model requested. Other access paths still need their own checks.

With a separate login, I can revoke the agent without revoking the person. Each connected system still has to enforce the change, and its logs should record the actions taken there.

Stopping the local process ends the local run. I also revoke the credential so later requests fail. Anything a remote service already accepted may keep moving, and completed writes or sent messages are still there.

A cooperative stop handles local work too. The operator sets a flag, and the application checks it before each next action. The current step may finish or leave a checkpoint; the next one doesn't begin. This works only if the application performs the check. A model promising to stop isn't the control.

Suppose an agent changes the wrong address on an order and sends it to a separate fulfillment service. The operator revokes the agent's grant and stops the local run. The fulfillment service may already have accepted the update.

The agent is stopped. The package may still be going to the wrong place.

The operator needs the remote request record and current order state. With a separate login, I can pull the actions made through that grant and ignore the person's work. A run identifier connects the writes from this task.

I also have to protect any legitimate work that happened later. If the customer corrected the address after the agent's bad write, blindly restoring the earlier value would erase the customer's change. I'd keep the old and new values with a version number, check whether the record has changed again, and send any conflict to a person.

If no later edit exists, the retained address still has to be checked against the customer's instruction before it is restored. The corrective write should check the version again so it can't overwrite a change that arrived during the investigation.

Fixing the record here doesn't fix what fulfillment already received. I record what was sent and whether the correction reached the recipient.

If I revoke the agent after the bad address is sent, I still need my own access to check the order, contact fulfillment, and record whether the correction arrived.

Sources: OWASP logging guidance; Azure's event-sourcing pattern.