One identity for people and agents: who may do what

A supplier’s bank account changes in the master data on a Thursday afternoon. The payment run on Friday uses the new account. On the following Tuesday the supplier calls to ask where the money is, and the finance team opens the audit log to see who made the change.

The log says: INTEGRATION_SVC. That account belongs to the middleware. Through it run the webshop sync, the warehouse connector, a scheduled cleanup script and, since the spring, two agents that update master data when a confirmed document says it should. Six processes, one name, one password that is stored in three places. The change was made by one of them, on behalf of someone, for a reason, and the record cannot say which, for whom or why.

This is not a security breach. Every process did what it was configured to do. It is an identity problem: the company gave its software one shared face, and a shared face cannot be asked questions. The moment agents start acting, the number of actions taken by that face multiplies, and every one of them is anonymous by construction.

What a shared service account hides

The actor. Six processes behind one name means the log records that something happened and not what did it. A person’s mistake, a script’s bug and an agent’s misjudgement look identical, and are corrected the same way: slowly.

The principal. An agent that updates a supplier does so because a person’s role asked for it or because a process allowed it. The service account carries no trace of that chain, so the question “who was this done for” has no answer either.

The scope. A service account accumulates rights. Each integration needed one more table, one more endpoint, and nobody removed the ones that are no longer used. The agent added last year inherited all of them, including the right to change a bank account it never needed.

The time. The account has been valid since it was created. A person’s access ends when they leave; a delegated task ends when it is done. The shared account ends never, so a credential leaked once is a credential leaked for good.

The boundary between reading and writing. The account that reads orders for a report is the same one that writes a payment file. One compromised script, one misconfigured prompt, and the read path becomes a write path. Why the write is the dangerous half is argued in an agent that writes to the ERP.

Permissions tied to tables. Database roles grant access to a table, not to a customer. An agent allowed to read the orders table reads every order, including the ones for the customer group its role should never see. The screen used to hide them; the agent does not use the screen.

What an agent’s identity has to look like

Its own name. Every agent is a principal in the directory, like a person and unlike a password in a configuration file. The log then names the agent, and a disputed change can be traced to one process rather than to a pool of six.

Delegated from a person or a role. An agent does not have rights of its own; it acts for someone. The purchasing agent acts under the purchasing role, within what that role may do, and the record shows the agent and the role together. If the person behind the role leaves, the delegation ends with them.

Scopes that expire. A delegation is for a task, a domain and a period. Reading open invoices for the next thirty days is a scope; reading everything for ever is a service account by another name. When the scope expires, the agent asks again, and the asking is recorded.

Permissions on business objects, not tables. This is where the ontology earns its place. The model defines a customer, an order, a supplier, a bank account, and the actions that exist on each: read, propose, change, approve. A permission then says that the service agent may read complaints for the customers of one region and propose answers, not that it may select from three tables. The same rule applies to people, so a person and an agent in the same role see exactly the same things.

Enforced on the server, read by everyone. The permission lives below the agent, in the layer that checks every request, not in the agent’s instructions. A prompt cannot grant itself access, and a person reading the model can see what each agent may do without reading any code.

The same answer for a person and an agent. “Who did this, for whom, on what evidence, and who approved it” is answered the same way whether the actor was a clerk or a process. If the record can answer it for staff and not for agents, agents are a hole in the audit, not a part of it.

A test you can run today

Open the audit log of your ERP or your accounting program and filter the last month by the technical accounts: the integration user, the API user, anything with “svc”, “sync” or “system” in its name. Count the changes. Then take five of them at random and try to answer, for each one, which process made the change and which person or role it was made for.

If you cannot answer within a few minutes from the record alone, without asking the IT team, every one of those changes is anonymous. Now list the processes that share each technical account and the rights the account holds. The difference between what each process needs and what the account has is the attack surface you have been running with, and it is the surface an agent would inherit on day one.

In Hurukan every request reaches the server with an identity: a person, an agent acting for a person or a process, or the system itself. Permissions are checked there, on the server, against the roles and rules the ontology defines on business objects, and every change is recorded with its author type, what changed and on whose approval. That is what makes an agent answerable in the same sentence as a member of staff, and it is the base layer of Hurukan, described in sovereignty is an architecture decision.