What is shipped, and what is not claimed.
This page is a list rather than an argument. Everything below is running today, everything labelled otherwise is labelled clearly, and nothing appears here that cannot be described from the current product record.
How is a caller authenticated?
Identity is the second stage of the governed flow and the only place a caller is established. Nothing downstream re-decides who is asking.
How is an action authorised?
In two stages that cannot be reordered. Hierarchy decides whether the target is inside the caller's reach at all; Policy then decides whether this particular action is allowed, starting from no.
The sibling-isolation property is worth stating plainly because it is structural rather than configured: two brands are sibling ORG nodes, visibility never moves sideways between siblings, and so there is no setting that makes one brand visible to the other.
What evidence survives an action?
Two layers, written by stages the acting engine does not control. Monitoring logs every action and every refusal; Audit seals the outcome.
That last row is the one that gives the record its value. An engine that produced its own audit entry could choose what to record; here the record is produced downstream of the work, by stages that sit outside the engine's control.
What stops untrusted data becoming of-record?
An approval gate that a submitting client cannot talk its way past. It re-checks the approver, requires cited sources, derives the trust grade itself, and refuses bulk material.
How are AI agents constrained?
By the same model as everyone else, plus one extra control. An AI agent is a NODE, so reach, policy, logging and sealing all apply unchanged, and AI governance additionally controls which AI models each level may use, with interactions logged.
This matters because an AI actor is the kind of participant most likely to be given a broad service credential and left alone. Here it has a position in the tree, a scoped session, a deny-by-default rule set, and a log entry for every action and every refusal, the same as a person.
Which controls exist but are not protecting anything yet?
Three. They are on this page rather than omitted, because the alternative, a security page that quietly counts unfinished controls as live, is exactly the failure mode a governance product should not have.
What is deliberately not claimed here?
Anything not listed above. This page is bounded by what the current product record describes, and it does not reach past it for effect.
If you have previously seen stronger or more exotic security claims attached to this brand, treat them as withdrawn pending confirmation rather than as background context for this page. The security properties VXCTRL relies on are the ordinary, checkable ones above: a known password hash, signed and revocable sessions, a rule set that starts from no, reach that only points downward, a log whose chain breaks if it is altered, and a ledger that is only ever appended to.
Where a control is built but not turned on, it is labelled. Where a domain exists but the product record does not describe it, it is named and left at that. Both choices cost the page some persuasiveness and are the right trade for a system whose whole job is to be believable after the fact.
Reviewing us for a security question?
Ask directly and we will answer in the same register as this page: what is shipped, what is built and not enabled, and what we are not claiming.
Questions people ask before they commit
How does VXCTRL handle passwords and sessions?
Passwords are hashed with argon2id. Sessions are verified, session tokens are signed, and sessions can be revoked. Each session is scoped to exactly what its holder can see and manage, and it expires and refreshes on a short TTL rather than being long-lived.
What stops one brand reaching another brand's data?
The shape of the org model. Visibility flows down only: you see your own node and everything below it, never sideways into a sibling brand, and Hierarchy checks the target of every governed write against the caller's reach before Policy is consulted.
How would you detect tampering with the record?
Monitoring writes every action and every refusal to a hash-chained operational log, so altering an earlier entry breaks the chain that follows it. Outcomes are additionally sealed onto an append-only audit ledger, where nothing is edited in place.
Is two-person control protecting sensitive actions today?
No. It is built and not yet enabled. When it is turned on, a sensitive action can require a second, distinct approver who co-signs the exact same write, bound byte-for-byte.
What security capabilities are built but not live?
Two-person control, identity lifecycle and access review. All three exist, the latter two as feature-gated modules, and none of them should be counted as a live control today.
Can a client tell VXCTRL how much to trust its own data?
No. The approval gate derives the trust grade, receipted, logged or inferred, from the sources cited for a fact. A client is never allowed to assert its own trust grade, and the gate refuses raw data dumps outright.
What security claims does this site make?
Only the ones listed on this page. Where a control is built but not yet enabled it is labelled as such, and capabilities that cannot be described from the current product record are left off rather than approximated.