Security and Sovereignty

Security below everything

In most business software, security is a feature of the screens: a menu item hidden from one role, a field greyed out for another. That stops being enough the moment agents arrive, because an agent does not use the screens. So in Hurukan security is the bottom layer, and everything above it — the models, the agents, the modules — passes through it on every read and every write.

Permissions held by the server

Every request reaches the server with an identity: a person, an agent acting for a person or a process, or the system itself. The server checks that identity against the roles and rules the Ontology defines before anything is read or written. The permission itself stays on the server rather than with the agent, so what an agent may do is set by the role it acts for, whatever a request asks.

The same layer enforces the rule that critical operations are approved by people. It is a check on the server, independent of any agent’s instructions and configuration.

An audit that names the actor

Each change is recorded with its author type — human, agent or system — together with what changed, when and on whose approval. Months later, a disputed price, a released order or a changed supplier bank account can be traced to the proposal, the evidence and the person who said yes.

Sovereignty in practice

A system that runs a whole company is the deepest dependency that company will ever take on. So Hurukan runs on infrastructure you choose, on an open-source stack that another team could maintain, with your data and your ontology exportable in open formats. The exit is agreed at the start, because on a system this deep it is the most important clause in the contract.

Holding up the layers above

Data is stored where this layer says and read only by those it allows. Agentic Logic and Super Intelligence see only what the identity they act for may see. That is why it sits at the base: every other layer is only as trustworthy as this one.