Doctrine
Governance is not security.
Security asks whether a system can be made to do something it should not. Governance asks whether the thing it did was authorised in the first place, who authorised it, and how somebody outside the organisation can check that answer afterwards. Both questions matter. Neither one answers the other, and a system can pass the first perfectly while failing the second completely.
The two words are increasingly used as if they were interchangeable. They are not, and the distinction is about to matter commercially, because software that answers only the first question is being sold to buyers who believe they are also getting the second.
Two different questions
Put an autonomous system in front of each discipline and they interrogate it differently.
Security asks about capability. Can this thing be compromised? Can its instructions be poisoned, its credentials stolen, its tools turned against the organisation that deployed it? Can an attacker reach further through it than they could without it? These are questions about what an adversary can force to happen.
Governance asks about authority. Was this action within the mandate the organisation actually granted? Which named person granted it, and when? If it turns out to have been wrong, is there a durable record that survives the people who made it, and can the permission be withdrawn? These are questions about what the organisation itself intended, and whether that intention is recoverable later by somebody who was not in the room.
An adversary is optional in the second set. That is the whole point. The governance failures worth worrying about mostly involve nobody breaking in at all.
The failure each one catches
A security failure looks like this: a system was manipulated into doing something outside its intended behaviour, and the organisation did not intend it and did not authorise it.
A governance failure looks like this: a system did exactly what it was configured to do, at speed, correctly, with no intrusion of any kind, and afterwards nobody could establish who had decided it should be allowed to, on what basis, or how to revoke that permission without breaking something else.
The second failure produces no alert. There is nothing to detect, because nothing was compromised. It surfaces later, usually when somebody outside the organisation asks a question that ought to have an easy answer and discovers that it does not.
Why a secure system can be an ungoverned one
Consider an organisation that has done the security work properly. Every automated actor holds its own identity. Credentials are scoped and rotated. Tool access is least-privilege. Traffic is monitored, anomalies are flagged, and no unauthorised party can reach anything.
Now ask three governance questions about the same organisation.
Who approved this scope?
Not which engineer configured it. Which accountable person decided that this class of action was acceptable, and is that decision written down anywhere a successor could find it?
What was the basis?
Was the decision made against a stated standard, or was it made because it was Thursday and the integration needed to ship?
Can somebody outside check?
If a customer, a regulator or a counterparty asks what this system is permitted to do on your behalf, is there an answer they can verify without taking your word for it?
A well-secured organisation can fail all three. The security controls are real and they are working. They were simply never designed to answer these questions, and there is no reason they should have been.
What governance requires that security does not
Four things, and none of them is a control in the security sense.
Attributable authority. Every permission traces to a person or body that held the standing to grant it. Configuration is not authorisation. Somebody has to have decided.
A named decider. Anonymous approval is the absence of governance wearing its clothes. If no name attaches to a decision, there is nobody to ask about it later and nobody who was accountable at the time.
A durable record. The decision outlives the meeting, the employee and the vendor. Institutional memory that lives only in the heads of current staff is not a record.
External checkability. The claim can be tested by somebody with no access to your systems and no reason to trust you. This is the hardest of the four and the one most often skipped, because it is the only one that requires giving up control of the answer.
That last requirement is the load-bearing one. A governance framework that only your own staff can inspect is a policy document. It becomes governance at the moment an outsider can check it and reach a conclusion you did not choose for them.
Where Lunara sits, and where it does not
This institution takes the governance side of that line, and it is worth being exact about how narrow the work currently is.
What Lunara does today is verify that a business is legally registered and controls the domain it operates from, have a named person review the evidence and sign the decision, and publish the result to a register that anyone can query for free, without an account, and that Lunara can withdraw. The regulatory obligations it tracks are published as signed, machine-readable data, so a reader can check the signature rather than trust the page. That is the whole of it.
Lunara does not secure anything. It runs no controls in your infrastructure, monitors no traffic, and blocks no action. If you need an adversary kept out, that is a different discipline and a different supplier.
Lunara does not audit models. It reads no code and evaluates no system behaviour. A verification of identity is not a statement about how a system performs.
Lunara does not certify compliance. Nothing here discharges a legal obligation. Lunara is a private standards body, not a regulator and not a notified body under the EU AI Act.
Lunara does not govern running systems. There is no product here that sits in front of an autonomous agent and permits or denies its actions. Saying otherwise would be a claim about software that does not exist, and this institution publishes a record of the times it has been wrong precisely so it does not accumulate claims like that.
What the four requirements above describe is the standard being argued for. What the register does today is a narrow application of it: one class of claim, checked by a person, published where it can be contradicted, and revocable. The argument is that the same shape scales to harder claims. The demonstration is small, and calling it anything else would be the failure this page is about.
How to tell which one you are being sold
Four questions separate the categories quickly, whoever is doing the selling.
Does it survive the absence of an attacker?
If every failure it describes involves a malicious party, it is security. Governance failures happen on quiet days.
Is a person named?
Governance attaches decisions to people who held the authority to make them. If the answer is a process with no name in it, the accountability is decorative.
Can somebody outside verify the claim?
If checking requires your cooperation, your logs or your dashboard, the claim is internal. That may be fine. It is not external verification, and it should not be described as such.
Can the status be taken away?
A credential that cannot be withdrawn carries no information, because nothing distinguishes an entity that still qualifies from one that no longer does.
A tool can be excellent and answer none of these. That is not a criticism of the tool. It is a reason not to buy it expecting the other thing.
Why this is published
Because a boundary that only exists internally is not a boundary. If Lunara holds that governance and security are different disciplines, that position should be written down, dated, and available to be argued with by anyone who thinks it is wrong. A position nobody can quote back at you is not a position, and this institution keeps a public record of its corrections for the same reason.
Position statement. This page makes no claim about any other organisation or product, and cites no figure it cannot support.