By Ming-Cheng Ho in Build In Public — 04 Sep 2026

Know Who, Then Ask Whether They May

A ten-person shop finds a promotion price changed twice. The owner asks who did it. Nobody can say.

A ten-person shop finds a promotion price changed twice. The owner asks who did it. The Google account is shared. So is the official Line. Nobody can say.

That used to be enough. The shop was small. The person who made the mistake was still in the room. Someone had asked. Someone remembered. Someone got an earful. The roster did not live in software. It lived in the air.

Now the same login may sit behind an agent. Agents do not leave a face in the room. You say add two more tickets; it may punch the request until the cap is gone. Afterward the log often shows only that something changed. The model did not suddenly get worse. Something the shop never wrote down just became visible.

Two questions

Security splits permission into two questions. Who are you. May you do this. In English those are authentication and authorization.

Enterprise software assumes both questions have a roster behind them: which people exist, which actions exist, where the boundary sits. Most small companies do not have that roster. Accounts are shared. The owner's card is on file. Work gets finished in a chat thread. That is not laziness. The company has not yet grown the infrastructure.

Once an agent can act, the missing roster shows up first. Authorization is the second question. The second question only works if the first one is stable. If you still cannot name the operator, a matrix of who may change a price or delete an order will be empty, or it will freeze the floor by afternoon. The matrix is not wrong. It assumes the roster already exists.

So the sequence often gets asked backwards. People see an agent that can rewrite a system and reach for authorization first. The path that actually fits is to invert the order large companies usually walk.

The enterprise sequence is too heavy

Enterprises tend to write policy first, put a gate on every call, and open the log when something explodes. Maker-checker, permission matrices, least privilege: all of that sits on a roster that is already there.

A small company does not have that premise. Force the template and you get a blank policy, or a business that locks on day one. Oliver Hart's point about incomplete contracts is old, and it fits. You cannot specify every future action in advance. Where the contract cannot speak, someone still has to decide. An agent that can write, edit, and delete enlarges the area the contract never covered. It does not remove the need for a person who can still be responsible. It makes that need urgent.

Anthropic's commerce agents are close to the thick enterprise version. The model stages the work. Money and inventory are not left to it. A person or a policy applies. Limits are checked against state after the write, and the same session is serialized. That is authorization, shipped as a product. A small company cannot wear it yet. It often cannot even say who is operating.

What it can do is a thinner procedure.

A model you can take with you

Identify → trail → open the gate only on write, edit, and delete.

Identify → trail → gate: bind a person, keep an append-only trail, ask a human only on write/edit/delete.

The order is fixed. Reverse it and the path jams.

Identify first

Not a job title in an RBAC table. A person who stays put: an employee's Google, Line, or email, or an agent bound to that person, so every later record can carry a name.

Stripe has already hit this in agentic checkout. Merchant accounts are often shared; memory has to be keyed to a person, not to an account. In big retail that is an edge case. In a small firm it is ordinary. Cursor, Devin, and Claude Managed Agents already emit event logs, trajectories, sessions. The missing piece is usually not the format of the log. It is that the log does not bind to a person. A trail under a shared login only proves that something moved.

Identify looks crude. Skip it and the next two steps spin.

Then keep a trail

Who, against which system, called what, changed what, and when. Do not block yet.

That sounds like leaving the key on the table. For a place with no roster, it is almost the only slope that moves. Without a trail, a permission table is a guess. With a trail, a few weeks later you can see that only two kinds of write ever happen. Then "may" and "may not" have something to be written from. If authorization is going to grow, it has to grow from behavior, not from an empty matrix.

The last year of infrastructure made this slope cheaper. Managed Agents treat a session as an append-only event log. Devin records the child trajectory. Cursor tracks how much of the model's work a human keeps. They log mostly to tune a harness. A small company can borrow the same pipe and change the purpose: every agent clocks in as a person, and every action lands on a record that cannot be edited.

Put the boundary on the table. Identity plus a trail is not safety. It is forensics, and it is learning. It will not stop a malicious employee. It will not stop a stolen login. It will tell you whose hand it was when something breaks. It will let an owner see, for the first time, what actually happens inside the tools. It will give later authorization something to write from. "We have logs, therefore we have governance" does not hold.

Then a gate

A trail without a gate is what you read after the fact. The fire is out. Then you try to see who walked through.

The third step is the one that can still be owned. Reads may run, and they should still be recorded. Writes, edits, deletes pause and ask a person: may this proceed. The agent proposes. A person nods or refuses. Effort can be automated. Answerability cannot move with it. If the write goes through, someone with a name said yes. If it does not, someone with a name said no.

Spend the gate. Ask on every read and people will approve everything, which is the same as having no gate. Attention is limited. Use it where reversal is expensive. A bad search is a line in the record. A bad delete is a hole in the data.

The gate is also what makes the name useful. At the moment of the question, the person should not be staring at "Are you sure?" They should be looking at a short history: this agent, acting as this employee, after this sequence, wants to edit this record. They are not guessing. They are reading, then deciding.

Enterprises already have a thicker version. Banks use two people watching each other. Anthropic calls it staging. Cursor's sandbox escalates when an action would leave the pen. A small company has no second department and no policy compiler. So the gate is narrower. It only stops actions that rewrite the world.

What this model is not

It is not Google Workspace, the company-account system that decides who may enter which door. It is not a complete RBAC matrix. And it cannot be enforced by writing "do not delete" in the instructions to the model. That sentence has no binding force. Models retry, rephrase, and treat prohibitions as suggestions.

It is also not a claim that small firms should never authorize. It is a claim that authorization drawn on a blank matrix looks like a rule and has no material yet. Authorization grown from a month of named trails, with a person still sitting on write, edit, and delete, has a chance to become the rule this shop actually uses. The two writes that keep happening can later become a standing yes. The strange ones stay at the door. If least privilege appears in a small company, it is more likely to grow from below.

The default that can ship is therefore thin. The agent's hands are tied to a person. The trail is append-only. Anything that writes, edits, or deletes waits for someone who can still be responsible. That is a path for generating permission, not a dashboard. You are not designing the matrix. You are designing the moment, when data would actually be rewritten, that a person can still stand there.