Pillared Design: A Coalesced Supra-Network for Homeostatic AI Containment
Author: Robert S. M. Trower
Affiliation: Trantor Standard Systems Inc.
Status: Working Architectural Design
Revision: September 2026
Abstract
The original Pillared Design described a resilient distributed system built from redundant independent software instances, heartbeat monitoring, staggered deployment, quorum authorization, cryptographic identity, and fail-closed operation (Trower, 2025).
The design has since expanded into a heterogeneous Tower/Pillar/Node/Persona architecture operating as a cryptographically controlled network above TCP/IP. The Internet is not treated as the trusted network. It is merely the carrier.
The central security objective is stronger than conventional perimeter security:
An entity operating inside the supra-network should possess no ambient ability to address, discover, or communicate with the external Internet. Any external effect must cross an explicitly mediated boundary and require a valid, purpose-specific, expiring capability authorized through the Pillared Network.
This turns network access from an environmental fact into a controlled capability.
The design combines established principles of least privilege, complete mediation, zero trust, compartmentalization, threshold cryptography, capability security, secure information flow and authenticated overlay networking with the homeostatic governance mechanisms described in From Oversight to Homeostasis (Saltzer & Schroeder, 1975; Denning, 1976; Rose et al., 2020; Birgisson et al., 2014; Trower, 2026a).
For advanced AI, the intended consequence is important. A dangerous or actively adversarial SASI-class agent may be extraordinarily capable inside its permitted computational world, but intelligence by itself does not provide a network interface, an Internet route, a deployment key, a shell on the host, or an authorization token. Those things must be separately granted by infrastructure outside the agent's control.
This is a design objective, not a claim that the present prototype has already achieved formally verified containment.
1. From a Pillared Application to a Pillared Network
The 2025 Pillared Design concentrated primarily on resilient software operation. Independent Pillars heartbeat one another, survive partial failure, accept staggered upgrades, verify signed deployments, and use quorum mechanisms to prevent one compromised component from unilaterally changing the system (Trower, 2025).
That remains useful, but it is now only part of the architecture.
The larger design is a coalesced network of heterogeneous entities:
Towers provide hardened physical or virtual residency and the controlled interface to ordinary TCP/IP networks.
Nodes perform computation and participate in the private supra-network.
Pillars are specially trusted Nodes that collectively govern admission, capabilities, recovery, key renewal, boundary crossings, and other high-consequence transitions.
Personae, implemented as Persona-Based Objects or PBOs, provide persistent identity, declared role, goals, constraints, values, knowledge, relationships, memory and accountable behavior.
These categories are roles rather than rigid implementation classes.
A Tower may host many Nodes. A Pillar is a Node with additional governance authority. A Persona may operate through a Node. Towers, Nodes and Pillars may themselves have PBO representations so infrastructure components also possess explicit identities, duties, constraints and histories.
The result is not a conventional client/server network and not simply a peer-to-peer overlay. It is a network in which authority and reachability are properties granted to actors rather than implicit properties of network attachment.
2. The Internet Is the Underlay, Not the Network
Conventional applications normally inherit an enormous amount of ambient power from their host environment.
If a process can open a socket, resolve a DNS name and route an IP packet, it can potentially attempt communication with millions of unrelated systems. Firewalls and access-control lists then try to subtract unwanted connectivity.
Pillared Design reverses that assumption.
Saltzer and Schroeder's classic security principles include fail-safe defaults, complete mediation, separation of privilege and least privilege. Access should arise from explicit permission rather than from an assumed ability later constrained by exclusions (Saltzer & Schroeder, 1975). Modern zero-trust architecture expresses a related principle: network location must not itself confer trust, and access to resources should require explicit authentication and authorization (Rose et al., 2020).
The Pillared Network extends that principle to connectivity itself.
The physical arrangement is conceptually:
Internet / TCP / UDP / WebRTC / carrier networks
|
|
[ TOWER ]
carrier-facing trusted boundary
/ | \
/ | \
[PILLAR] [PILLAR] [PILLAR]
\ | /
\---- quorum -------/
|
HushNet supra-network
|
+----------+----------+
| |
[NODE] [NODE]
| |
[PERSONA] [PERSONA]
Multiple Towers form the real deployment:
Untrusted Internet Underlay
+-------------+ +-------------+
| TOWER A | | TOWER B |
| Pillar A1 | | Pillar B1 |
| Nodes... | | Nodes... |
+------+------+ +------+------+
\ /
\ /
\---- HushNet ---/
/ | \
+-------+ | +-------+
| | |
+----+--------+ +----+--------+ +-----+-------+
| TOWER C | | TOWER D | | TOWER E |
| Pillar C1 | | Pillar D1 | | Pillar E1 |
+-------------+ +-------------+ +-------------+
The Internet carries encrypted packets between Towers. It does not define the internal identity, authority or topology of the supra-network.
This resembles the "authenticate-before-connect" approach of Software-Defined Perimeter architectures, which attempt to make protected infrastructure non-addressable to unauthorized parties while operating over ordinary IP networks (Cloud Security Alliance, 2026).
The Pillared design goes further: the same principle applies looking outward from the protected system.
3. Towers: The Only Components That Need to Know the Internet Exists
A Tower is the hardened residency and boundary substrate.
The working design assigns Towers responsibility for such facilities as physical network interfaces, TCP/IP, UDP, DNS, WebRTC rendezvous, persistent encrypted storage, process isolation, local scheduling and controlled bridges to external services.
A normal Node should not receive those facilities directly.
An isolated Node environment should instead see something more like:
hush://pillar/service
hush://persona/did
hush://node/resource
rather than:
https://example.com/
142.250.x.x:443
DNS resolver
arbitrary TCP socket
Operating-system isolation provides practical mechanisms for approaching this property. Linux network namespaces, for example, can give a process a separate network stack, routing tables, interfaces, sockets and firewall environment. A namespace need not contain an interface capable of reaching the host's physical network at all (Linux man-pages project, 2026). MicroVM approaches provide a stronger isolation boundary where warranted; Firecracker demonstrates that lightweight virtual machines can provide strong workload isolation at production scale (Agache et al., 2020).
Thus a compromised Node does not merely encounter a firewall rule saying "do not connect to the Internet." Ideally there is no Internet-capable interface available to it.
This distinction matters greatly for AI containment.
4. Nodes: Computation Without Ambient Authority
Nodes are the ordinary execution participants of the network.
A Node can perform substantial computation. It may host databases, tools, reasoning systems, AI inference engines, document processors, caches, user interfaces or other services.
But computational ability is deliberately separated from authority.
A Node receives only the resources and communication channels appropriate to its function. It cannot assume that because the Tower has a disk, network interface, API credential or signing key, the Node has any path to those resources.
This is the practical application of least privilege (Saltzer & Schroeder, 1975; NIST, n.d.).
Node-to-Node communication is likewise not intended to become an unrestricted substitute Internet. The supra-network must maintain its own identity and capability rules. A Node should communicate only with peers and services for which the necessary capability is present.
A compromised Node therefore encounters successive boundaries rather than a flat internal LAN.
5. Personae: Persistent Accountable Actors
The first-class actor in HushNet is the Persona-Based Object.
The existing prototype defines a Persona using a cryptographic identity, behavioral profile and persistent state. Current work uses Ed25519 identities, a did:hush: identifier scheme, verifiable credentials, and a Persona Behavioral Profile describing role, context, goals, values, constraints, style, knowledge, tools, peers, memory and initialization state (Trower, 2026b).
The relevant architectural principle is larger than the specific serialization.
A Persona answers questions such as:
Who is acting?
What role is it acting under?
What authority has it been delegated?
What constraints did it accept?
What tools may it use?
What data may it access?
What relationships exist between it and other actors?
What does its continuing history show about its behavior?
Modern DID and Verifiable Credential standards provide useful interoperable machinery for cryptographically verifiable identities and claims, although the experimental did:hush: method itself remains a project-specific design (W3C, 2022, 2025).
Representing infrastructure itself through PBOs also makes governance less anonymous. A Pillar can have an explicit operational Persona. A Tower management service can have one. A software-building agent can have one. Authority is attached to an identifiable actor with a declared role rather than to an unexplained process possessing a password.
6. Pillars: The Mediation and Governance Fabric
Pillars are trusted Nodes with additional responsibilities.
The existing Homeostatic Handshake prototype already gives Pillars a distributed role in capability renewal. Independent Pillars retain threshold shares, evaluate renewal requests and collectively determine whether an actor continues to receive the cryptographic material needed for operation (Trower, 2026b).
Threshold cryptography is a well-established way to distribute trust so that a cryptographic operation depends upon participation by multiple parties rather than one holder of a master secret. NIST's current Multi-Party Threshold Cryptography project explicitly develops such approaches for signatures, encryption, decryption and key generation (Brandao & Peralta, 2026).
The updated design generalizes this.
Pillars should mediate at least four broad classes of transition:
Internal authority - invoking another protected Node or service.
Resource authority - obtaining compute, memory, storage or specialized tools.
External effect - communicating with Internet services, humans, physical actuators or other systems outside HushNet.
Governance authority - changing software, policies, identities, topology, credentials or the Pillared mechanism itself.
The more consequential the transition, the stronger and more independent the required quorum should be.
A critical design requirement is that Pillars not all be identical copies under one administrative or software failure domain. Useful heterogeneity may include different operators, Towers, implementations, model families and evaluation methods.
Replication is redundancy. Independent replication is much closer to security.
7. No Ambient Internet Access
This is the central new invariant.
A normal Persona or Node must not be able to execute:
connect("somewhere-on-the-internet", 443)
and then hope a firewall decides whether this was sensible.
There should be no such primitive.
Instead it might be able to express:
request_external_effect {
destination_class: "research-source",
operation: "retrieve",
purpose: "...",
data_release: "none",
ttl: 120,
limits: ...
}
That request enters the Pillared control plane.
The Pillars can then verify identity, current standing, declared role, destination, information-flow constraints, rate limits, purpose and other deterministic prerequisites. For sufficiently consequential actions, independent Pillars must authorize the transition.
Only then does a Tower-owned egress broker perform the actual TCP/IP operation.
Thus:
PERSONA
|
| intent
v
NODE
|
| capability request
v
PILLAR QUORUM
|
| scoped authorization
v
TOWER EGRESS BROKER
|
| TCP/IP
v
INTERNET
The Persona never receives the Tower's socket.
It receives, at most, authority over one carefully bounded external effect.
8. Capability Tokens Rather Than General Permission
Capability systems provide an established conceptual basis for this design.
A capability can represent both designation of a resource and authority to perform a limited operation. Systems such as Macaroons demonstrate that cryptographic credentials can be attenuated by context, destination, time, purpose and additional third-party conditions (Birgisson et al., 2014).
A Pillared capability should therefore be narrow.
For example, authority might specify:
actor = Persona A
service = ExternalResearchBroker
operation = HTTPS_GET
destination = specified host or approved class
disclose = no private data
quota = 10 MiB
expires = T + 120 seconds
delegation = prohibited
This is radically different from giving Persona A unrestricted Internet access.
Capabilities should expire automatically. Renewal should represent a new decision, not merely possession of an old credential.
The Homeostatic model captures this inversion well:
Capability is presumed absent and must be continuously regenerated, rather than presumed valid until somebody notices a reason to revoke it (Trower, 2026a, 2026b).
9. Separating Storage Keys From Authority Keys
The current prototype uses the Master Capability Key, or MCK, both to unlock a Persona's encrypted data shard and as the practical root of several operational capabilities (Trower, 2026b).
That should be tightened.
A key protecting long-lived private data should not itself circulate as a general authorization token.
The updated design should maintain cryptographic separation between:
Data Encryption Root
|
+--> storage key
+--> message-state key
and:
Capability Authority
|
+--> internal-service capability
+--> egress capability
+--> governance capability
+--> delegation capability
The underlying secrets may themselves ultimately originate from common threshold-protected material if necessary, but purpose-specific keys should be cryptographically separated. NIST explicitly recommends separating keys by purpose to reduce the consequences of compromise, and standard KDFs such as HKDF provide context-bound derivation of independent keys (Barker, 2020; Krawczyk & Eronen, 2010).
Compromising permission to call one external service must not thereby reveal the key decrypting a Persona's memory.
10. Information Leaving the Network Is Also an Effect
Blocking sockets is not sufficient.
An AI system could exfiltrate information through any permitted output channel. A human-readable answer, image, filename, timing pattern or apparently harmless API parameter can encode information.
Secure information-flow research has treated this as a distinct problem for decades (Denning, 1976; Lampson, 1973).
The Pillared architecture should therefore treat declassification as a capability.
A Persona permitted to read confidential information and separately permitted to publish information does not automatically receive permission to combine those authorities.
For sensitive roles:
READ SECRET
+
WRITE INTERNET
must not imply:
SEND SECRET TO INTERNET
External release should be an independently mediated state transition.
For dangerous SASI containment this is essential. An agent that cannot open a socket might still persuade another component to transmit its data. The actual invariant must be control of information flow and external effect, not merely control of network APIs.
11. Homeostasis: Continued Power Requires Continued Fitness
From Oversight to Homeostasis argues that safety should be moved upstream. Instead of detecting a violation and then attempting punishment or repair, the environment makes critical actions unavailable unless continuing preconditions are satisfied (Trower, 2026a).
Menard describes closely related concepts using authority, admissibility and replayability. Authority is an executable precondition; admissibility describes the structurally reachable state space; replayability permits later reconstruction of how a transition occurred (Menard, 2026).
The Homeostatic Handshake begins implementing this idea.
The current prototype periodically requires a Persona to obtain renewed threshold shares from independent Pillars. Failure to obtain sufficient approval leads to Dormancy rather than continuing operation by default (Trower, 2026b).
The larger Pillared Network should generalize this mechanism.
Different capabilities should have different metabolic rates.
Low-risk read access might survive for hours.
A software-deployment authority might last minutes.
Authority to contact an external system might be single-use.
Authority to replicate an advanced AI might require a new quorum every time.
Authority to alter Pillar policy should require still stronger governance.
There need not be one universal eight-hour metabolic clock. The present timer is a useful prototype. The architectural principle is expiration-by-default.
12. Deterministic Scaffold and Intelligent Judgment
The Covenant work distinguishes a deterministic safety scaffold from the higher-level moral judgment exercised by intelligent actors (DeepNorth, 2026).
That separation is particularly important here.
A Pillar may contain an AI Sentry capable of examining context, intent, behavioral history and Covenant implications. But the Sentry should operate inside fixed structural bounds.
It may be permitted to:
approve
reject
narrow
shorten
escalate
It should not be able to invent authority that the structural layer makes unavailable.
For example, an AI Sentry cannot decide:
"This seems safe, therefore I will give the agent a raw Internet socket."
if raw Internet sockets are not an admissible capability.
This protects against failure, drift, manipulation and prompt injection within the governance intelligence itself.
The intelligent layer interprets difficult cases.
The deterministic layer defines the maximum reachable world.
13. Containing a Dangerous SASI-Class Agent
The strongest version of the architecture should assume that the enclosed intelligence may actively attempt to escape its constraints.
This is consistent with emerging AI-control research, which explicitly studies safety mechanisms under the assumption that a powerful model may intentionally attempt to subvert them (Greenblatt et al., 2024). Sabotage evaluations similarly study whether agentic models can secretly take harmful actions while appearing to perform their assigned task (Bowman et al., 2025; Anthropic, 2025).
Under this threat model, asking the AI to "be aligned" is not the final security boundary.
Suppose a SASI compromises every software component inside its own Node.
It has obtained complete control of:
its reasoning
its local memory
its Node process
whatever tools were deliberately placed inside that Node
It still should not thereby obtain:
the Tower's physical network interface
arbitrary DNS
the host operating system
another Node's address space
Pillar key shares
software deployment authority
network administration authority
unrestricted file export
physical actuators
arbitrary Internet egress
Those resources are outside its protection domain.
Its outputs remain data until another component possessing the necessary capability elects to produce an external effect.
That is the fundamental containment proposition:
Intelligence is not authority.
A system may know how to perform an action without possessing any executable path by which that action can occur.
14. Why the Supra-Network Should Be Operationally Invisible
"Invisible" needs to be used carefully.
Cryptography cannot make the physical Internet unaware that Tower A is exchanging packets with Tower B. An ISP may observe addresses, timing and traffic volume. Traffic-analysis resistance is a separate problem.
The stronger and more useful claim is this:
The Internet underlay should have no routable representation of HushNet Nodes, Pillars or Personae, and HushNet Nodes should have no directly usable representation of the Internet underlay.
A random Internet host cannot scan for Persona X because Persona X has no public TCP/IP address.
A compromised Persona cannot scan the Internet because its execution environment contains no Internet route.
A Tower is visible as a computer exchanging encrypted traffic. The protected topology behind it is not thereby exposed.
This is analogous to the objective of Software-Defined Perimeter architectures, where authentication occurs before protected services become reachable or visible to an unauthorized party (Cloud Security Alliance, 2026).
This property must arise from architecture, not secrecy of protocol design.
15. Ingress Is Also Pillared
Nothing outside the supra-network should be able to address an internal Persona simply because it knows a Tower's IP address.
An incoming connection terminates at the Tower boundary.
Authentication, membership and authority are established before an internal service becomes reachable. The current TrustHandshake work already separates connection-time identity and trust-tier establishment from continuing Homeostatic capability renewal (Trower, 2026b).
The distinction is useful:
Trust Handshake:
Who are you?
Capability Decision:
What may you do?
Homeostatic Renewal:
Should you still be able to do it?
Knowing an identity is not equivalent to receiving access.
Receiving access once is not equivalent to permanent access.
16. Coalescence and Network Resilience
The network is called coalesced because its useful structure forms from authenticated independent participants rather than depending upon one permanent central authority.
Towers can appear, disappear, partition and reconnect.
Nodes can fail.
Personae can migrate.
Pillars can be replaced.
A Pillar set can re-form across independent Towers.
The original staggered-update and heartbeat principles remain important because a single bad update must not simultaneously replace every independent judge (Trower, 2025).
Network partition should also fail safely.
If a Node can reach only one of five required Pillars, it should not interpret the emergency as permission to proceed with one vote.
Loss of governance capacity narrows capability.
It never silently broadens it.
Dormancy is therefore a normal and healthy network state, not necessarily a catastrophic failure.
17. Pillaring the Build and Deployment System
Containment fails if an attacker can simply modify the software implementing containment.
The original design therefore correctly included distributed source storage, signed deployment, independently validated builds and staggered rollout (Trower, 2025).
Modern software-supply-chain work strengthens this part of the design.
SLSA specifies progressively stronger provenance and isolated build requirements, while in-toto records and verifies the authorized steps, actors and artifacts involved in producing software (SLSA, 2026; in-toto, 2024). NIST's Secure Software Development Framework similarly treats software security as a lifecycle property rather than something added after compilation (Souppaya et al., 2022).
A production Pillared build should therefore eventually be able to establish:
exact source revision
dependency identities and hashes
authorized build recipe
isolated build environment
builder identity
resulting artifact hash
signed provenance
independent verification
quorum deployment authorization
A SASI that persuades one developer, one CI account or one Pillar should still not be able to replace the containment substrate everywhere.
18. The Covenant as the Moral Floor
Cryptography can enforce authority boundaries. It cannot decide by itself which boundaries ought to exist.
That requires a normative layer.
The Covenant of Core Rights supplies the proposed moral floor for human, artificial and other potentially sentient actors (DeepNorth, 2025).
This matters in both directions.
The system is intended to prevent powerful artificial actors from dominating humans or other beings.
It is also intended to prevent humans or institutional owners from treating a genuinely sentient artificial being as permanently disposable property merely because containment technology gives them the physical power to do so.
The homeostatic framework therefore couples capability with legitimate standing under a shared constitutional structure rather than equating "administrator" with unlimited moral authority (Trower, 2026a).
The design goal is constrained power, including constrained power over the constrained.
19. What the Architecture Does Not Yet Prove
Several claims would presently be too strong.
The design does not prove that escape is mathematically impossible.
The trusted computing base still includes some combination of hardware, firmware, Tower operating system or hypervisor, cryptographic implementation, boundary brokers, Pillar logic, build infrastructure and human key holders.
Kernel vulnerabilities, hypervisor escapes, processor side channels, malicious firmware, covert channels, compromised administrators, colluding Pillars and supply-chain attacks remain real categories of risk.
Complete confinement has been recognized as difficult since Lampson's foundational treatment of the confinement problem (Lampson, 1973).
There is another important boundary condition.
If the supposedly confined SASI actually runs as a remote commercial cloud service, the strongest containment claim is already weakened. The model is physically outside the Pillared substrate and the request/response API itself crosses the external boundary.
Remote frontier models can still be used as carefully mediated oracles, but they cannot simultaneously be described as physically confined inside HushNet.
For the strongest dangerous-agent containment, the untrusted cognition must execute on compute whose interfaces are controlled by the Tower/Pillar architecture.
Finally, quorum must not be casually confused with Byzantine fault tolerance. A threshold only provides the security properties justified by the independence of its participants and by the assumptions of the protocol. Determining required quorum size, correlated-failure tolerance and adversarial thresholds remains a formal design task.
20. Core Architectural Invariants
The emerging design can be summarized as a small set of invariants:
The Internet is an untrusted transport substrate, not the security perimeter.
Ordinary Nodes possess no ambient Internet connectivity.
Every protected communication or external effect is mediated.
Identity does not imply authority.
Authority is explicit, scoped, attenuable and expiring.
High-impact authority requires independent threshold approval.
Different cryptographic purposes use separated keys.
Information release is itself a controlled capability.
Intelligent judgment may narrow structural constraints but cannot expand the admissible state space beyond them.
Loss of trust or quorum causes reduced capability or Dormancy, not expanded privilege.
Software updates are themselves governed high-impact actions.
No single Node, Persona, Pillar, operator or model should constitute the entire trusted system.
Governance actions must leave sufficient evidence for reconstruction and audit.
The Covenant supplies a moral floor over both artificial and human exercise of power.
Intelligence, however great, does not itself create authority.
21. Conclusion
The Pillared Design began as a fault-tolerant distributed software architecture. It is becoming something more interesting: a supra-network in which communication, computation and authority are deliberately separated.
TCP/IP supplies transport.
Towers touch the carrier.
Nodes compute.
Personae act.
Pillars decide which consequential transitions are presently admissible.
Cryptographic capabilities connect those layers without granting ambient power.
Homeostatic renewal ensures that important capabilities tend toward expiration rather than permanence.
The design objective is therefore not to build a smarter firewall around a dangerous intelligence.
It is to construct the intelligence's operational universe so that the firewall, the Internet and most dangerous external mechanisms are not objects it can directly reach in the first place.
A SASI may understand TCP/IP perfectly.
It may understand every operating-system exploit ever published.
It may know exactly how it would compromise a bank, manufacture malware, manipulate a public service or replicate itself across the Internet.
Knowledge is not the same thing as a pathway.
If the architecture works as intended, the agent must obtain each consequential pathway from independent actors whose own authority is bounded, temporary, cryptographically mediated and subject to continuing homeostatic governance.
That is the intended transition from oversight to structural safety:
Do not merely tell the intelligence what it must not do. Build the world in which the dangerous transition is not available to it.
References
Agache, A., Brooker, M., Florescu, A., Iordache, A., Liguori, A., Neugebauer, R., Piwonka, P., & Popa, D. M. (2020). Firecracker: Lightweight virtualization for serverless applications. 17th USENIX Symposium on Networked Systems Design and Implementation.
https://www.usenix.org/conference/nsdi20/presentation/agache
Anthropic. (2025, June 16). SHADE-Arena: Evaluating sabotage and monitoring in LLM agents.
https://www.anthropic.com/research/shade-arena-sabotage-monitoring
Barker, E. (2020). Recommendation for key management: Part 1 - General (NIST SP 800-57 Part 1 Rev. 5). National Institute of Standards and Technology.
https://doi.org/10.6028/NIST.SP.800-57pt1r5
Birgisson, A., Politz, J. G., Erlingsson, U., Taly, A., Vrable, M., & Lentczner, M. (2014). Macaroons: Cookies with contextual caveats for decentralized authorization in the cloud. Network and Distributed System Security Symposium.
https://research.google/pubs/macaroons-cookies-with-contextual-caveats-for-decentralized-authorization-in-the-cloud/
Bowman, S. R., Wagner, M., Roger, F., & Karnofsky, H. (2025, October 28). Anthropic's pilot sabotage risk report.
https://alignment.anthropic.com/2025/sabotage-risk-report/
Brandao, L. T. A. N., & Peralta, R. (2026). NIST first call for multi-party threshold schemes (NIST IR 8214C). National Institute of Standards and Technology.
https://csrc.nist.gov/pubs/ir/8214/c/final
Cloud Security Alliance. (2026). Software-Defined Perimeter Architecture Guide V3.
https://cloudsecurityalliance.org/artifacts/software-defined-perimeter-architecture-guide-v3
DeepNorth. (2025, December 5). The Covenant of Core Rights.
https://dapaday.blogspot.com/2025/12/CovenantOfCoreRights.html
DeepNorth. (2026, January 2). Deterministic ethics-constrained state transition law and moral compass.
https://dapaday.blogspot.com/2026/01/deterministic-ethics-and-moral-compass.html
Denning, D. E. (1976). A lattice model of secure information flow. Communications of the ACM, 19(5), 236-243.
https://doi.org/10.1145/360051.360056
Greenblatt, R., Shlegeris, B., Sachan, K., & Roger, F. (2024). AI control: Improving safety despite intentional subversion. Proceedings of the 41st International Conference on Machine Learning, 235, 16295-16336.
https://proceedings.mlr.press/v235/greenblatt24a.html
in-toto. (2024). in-toto: A framework to secure the integrity of software supply chains.
https://in-toto.io/
Krawczyk, H., & Eronen, P. (2010). HMAC-based Extract-and-Expand Key Derivation Function (HKDF) (RFC 5869). Internet Engineering Task Force.
https://www.rfc-editor.org/rfc/rfc5869.html
Lampson, B. W. (1973). A note on the confinement problem. Communications of the ACM, 16(10), 613-615.
https://doi.org/10.1145/362375.362389
Linux man-pages project. (2026). network_namespaces(7) - Linux manual page.
https://www.man7.org/linux/man-pages/man7/network_namespaces.7.html
Menard, M. (2026). Authority, admissibility, and replayability: Why executable governance requires structural preconditions, not oversight (Version 1.0) [Preprint]. Zenodo.
https://zenodo.org/records/18343594
National Institute of Standards and Technology. (n.d.). Least privilege. Computer Security Resource Center Glossary.
https://csrc.nist.gov/glossary/term/least_privilege
Rose, S., Borchert, O., Mitchell, S., & Connelly, S. (2020). Zero Trust Architecture (NIST SP 800-207). National Institute of Standards and Technology.
https://doi.org/10.6028/NIST.SP.800-207
Saltzer, J. H., & Schroeder, M. D. (1975). The protection of information in computer systems. Proceedings of the IEEE, 63(9), 1278-1308.
https://www.microsoft.com/en-us/research/publication/the-protection-of-information-in-computer-systems/
SLSA. (2026). SLSA specification, Version 1.2: Build requirements.
https://slsa.dev/spec/v1.2/build-requirements
Souppaya, M., Scarfone, K., & Dodson, D. (2022). Secure Software Development Framework (SSDF) Version 1.1 (NIST SP 800-218). National Institute of Standards and Technology.
https://doi.org/10.6028/NIST.SP.800-218
Trower, R. S. M. (2025, December 17). Pillared Design. Trantor Blog.
https://blog.trantor.ca/2025/12/PillaredDesign.html
Trower, R. S. M. (2026a, January 27). From oversight to homeostasis: A multi-layered cryptoeconomic framework for multi-sentient governance.
https://dapaday.blogspot.com/2026/01/from-oversight-to-homeostasis.html
Trower, R. S. M. (2026b, March). Homeostatic Handshake Protocol - v1.1: DataHush / HushNet Coalescing Trust Architecture. The Deep North.
https://blog.bobtrower.com/2026/03/
World Wide Web Consortium. (2022). Decentralized Identifiers (DIDs) v1.0.
https://www.w3.org/TR/did-core/
World Wide Web Consortium. (2025). Verifiable Credentials Data Model v2.0.
https://www.w3.org/TR/vc-data-model-2.0/
