Bare Metal Security: Moving Governance to the Execution Gate
August 22, 2026
Like
Downloadable templates
This post explores a new security model that shifts governance to the execution boundary, using Linux primitives to enforce authorization before workloads run.
Bare Metal Security: From Software-Enforced Substrate to Hardware-Rooted Execution Governance
Introduction
Traditional security is largely organized around detection and response.
A workload starts running. Security controls monitor it, identify suspicious behavior, generate alerts, and attempt to contain the resulting damage.
That model is necessary, but it creates a persistent operational cycle:
Execute
↓
Observe
↓
Detect
↓
Respond
↓
Patch
↓
Monitor again
This paper explores a different approach:
Instead of treating security only as a mechanism for detecting bad execution, make authorization a prerequisite for entering a protected execution state.
The proposed Bare Metal / Substrate Security Model moves governance closer to the execution boundary.
The model begins with a simple principle:
Intent
↓
Authority
↓
Authorization
↓
Execution Gate
↓
Restricted Execution
↓
Audit
The first version can be implemented entirely with software using Linux security primitives.
A second, stronger version adds hardware-backed trust so that authorization is tied not only to the workload and policy, but also to the integrity of the platform on which that workload executes.
Part I — Software-Enforced Substrate Security
1. The Core Idea
The first version does not depend on specialized hardware.
It uses Linux as the enforcement substrate and combines:
- explicit intent
- authority evaluation
- signed authorization
- workload identity
- policy binding
- a pre-execution gate
- Landlock
- seccomp
no_new_privs- process isolation
- audit and supervision
The central invariant is:
No protected workload should enter its authorized execution state without a valid authorization decision.
This is deliberately narrower than saying that no CPU instruction can ever execute without authorization.
The system is controlling the protected workload and its consequential operations, not attempting to turn the processor into a policy engine.
2. Traditional Security vs. Substrate Security
Traditional model
Application
↓
Operating System
↓
Execution
↓
Monitoring
↓
Detection
↓
Response
↓
Remediation
The security decision often occurs after execution has already begun.
Substrate model
Intent
↓
Authority
↓
Authorization
↓
Execution Gate
↓
Linux Security Context
↓
Workload
↓
Audit
The critical difference is the Execution Gate.
The gate determines whether a protected workload is allowed to enter its authorized execution context.
3. Quiescent by Default
The first principle is:
No valid authorization, no protected execution context.
A request does not immediately become an executable process.
Instead:
Request
↓
Authorization
↓
Valid?
┌─┴─┐
No Yes
↓ ↓
Deny Build restricted context
The protected workload remains unstarted until its execution requirements have been satisfied.
This is the software interpretation of quiescent by default.
It does not claim that an entire physical machine is dormant.
It means that the protected workload does not receive permission to perform its consequential action until the required authorization sequence has completed.
4. Intent
Every consequential operation begins with a structured intent.
For example:
{
"subject": "deployment-agent",
"action": "deploy",
"resource": "production-api",
"reason": "release-2026-08-22"
}
Intent creates a distinction between:
"I want this action"
and:
"This action is authorized to execute"
That distinction is fundamental.
5. Authority and Policy
The authority layer answers:
Who is allowed to perform this action?
For example:
Agent A
↓
Deploy production
↓
Policy
↓
DENY
while:
Release Manager
↓
Deploy production
↓
Policy
↓
ALLOW
The authority service should not directly execute the workload.
Its job is to transform policy into an explicit authorization decision.
This creates a clean separation:
Authority
↓
Decision
↓
Execution Gate
6. The Signed Authorization Receipt
An approved request produces a short-lived authorization receipt.
Conceptually:
{
"subject": "deployment-agent",
"action": "deploy",
"resource": "production-api",
"workload_digest": "sha256:ABC123",
"policy_version": "42",
"scope": {
"filesystem": [
"/srv/releases/current"
],
"network": [
"api.example.com:443"
]
},
"issued_at": "2026-08-22T11:00:00Z",
"expires_at": "2026-08-22T11:05:00Z",
"nonce": "91a7",
"signature": "..."
}
The receipt binds:
WHO
+
WHAT
+
WHERE
+
WHICH WORKLOAD
+
WHICH POLICY
+
HOW LONG
This turns authorization into a concrete machine-verifiable object.
7. The Substrate Execution Gate
The Substrate Execution Gate (SEG) is the core component.
Before launching a protected workload, it verifies:
Signature ✓
Subject ✓
Action ✓
Resource ✓
Workload identity ✓
Policy version ✓
Scope ✓
Expiry ✓
Revocation status ✓
If the checks pass:
PASS
↓
Create restricted execution context
↓
Launch workload
If any critical check fails:
FAIL
↓
NO PROTECTED EXECUTION
This is the technical interpretation of:
No receipt → no execution context.
8. Workload Identity
Authorization should not simply say:
"Agent X may deploy."
It should be bound to the exact workload that was approved.
For example:
Expected workload:
sha256:ABC123
Actual workload:
sha256:XYZ999
Result:
DENY
This prevents an attacker from replacing an authorized binary with another executable while retaining the authorization request.
9. Policy Version Binding
Authorization should also be bound to the policy under which it was issued.
Example:
Receipt:
Policy v42
Current policy:
Policy v43
If v43 invalidates the previous authorization, the old receipt must not automatically remain valid.
This creates a mechanism for controlling policy drift.
Policy change
↓
Old authorization becomes stale
↓
Reauthorization required
10. Linux Enforcement Layer
Once authorization is validated, the workload should still not receive unrestricted access to the Linux system.
The execution gate builds a constrained execution context.
A practical first implementation combines:
Landlock
+
seccomp
+
no_new_privs
+
Linux privilege/capability controls
+
Namespaces / cgroups where appropriate
11. Landlock
Landlock provides kernel-enforced sandboxing and access-control mechanisms that can restrict what a process and its descendants may access.
A workload could receive a policy such as:
/app/bin → READ + EXECUTE
/app/data → READ + WRITE
/tmp/app → READ + WRITE
/etc → DENY
/home → DENY
SSH → DENY
HTTPS/443 → ALLOW
The application cannot simply decide to grant itself additional Landlock access.
The restrictions are enforced by the Linux kernel.
Landlock therefore becomes one of the important substrate enforcement primitives in the architecture.
12. Seccomp
Landlock is not intended to solve every operating-system security problem.
Seccomp provides another layer by restricting system calls.
A profile could allow the syscalls required by a workload while rejecting dangerous or unnecessary operations.
Conceptually:
Application
↓
System Call
↓
Seccomp
┌──┴─────────┐
ALLOW DENY
This reduces the system-call surface exposed by the workload.
13. no_new_privs
Before the workload executes, the launcher can enable no_new_privs.
The goal is to prevent the process from acquiring additional privilege through mechanisms such as set-user-ID/set-group-ID transitions or file capabilities.
The execution sequence therefore becomes:
Identify workload
↓
Drop unnecessary privileges
↓
Enable no_new_privs
↓
Apply Landlock
↓
Apply seccomp
↓
Execute workload
14. The Software Architecture
[CONTROL PLAN](/blog/control-plans-for-gcc-process-stability-3)E
│
┌─────────────────┼─────────────────┐
│ │ │
▼ ▼ ▼
Policy Authority Audit
│ │
└──────────┬──────┘
▼
Authorization API
│
Signed Receipt
│
▼
┌───────────────────┐
│ Substrate Gate │
│ │
│ Verify receipt │
│ Verify workload │
│ Verify policy │
│ Verify scope │
└─────────┬─────────┘
│
┌─────────┼─────────┐
▼ ▼ ▼
Landlock Seccomp no_new_privs
│ │ │
└─────────┼─────────┘
▼
Workload
│
▼
Audit
15. Failure Model
A secure system must define what happens when things go wrong.
Missing receipt
NO RECEIPT
↓
DENY
Invalid signature
INVALID SIGNATURE
↓
DENY
Expired receipt
EXPIRED
↓
DENY
Workload mismatch
HASH MISMATCH
↓
DENY
Policy mismatch
STALE POLICY
↓
DENY / REAUTHORIZE
Scope violation
UNAUTHORIZED ACCESS
↓
KERNEL ENFORCEMENT
↓
DENY
The security model is therefore fail-closed for the protected action.
16. Audit and the "Drift Tax"
Every authorization and execution should produce an auditable event.
For example:
{
"event": "EXECUTION_STARTED",
"receipt_id": "r-8f912",
"subject": "deployment-agent",
"workload": "sha256:ABC123",
"action": "deploy",
"resource": "production-api",
"policy_version": "42",
"timestamp": "..."
}
Drift can then be defined operationally as divergence between:
Authorized state
and
Actual execution state
Examples include:
- workload changed
- policy changed
- authorization expired
- runtime scope changed
- platform configuration changed
The system can therefore turn drift from something discovered only after the fact into a condition that causes reauthorization or denial.
This is the foundation of the proposed Drift Tax concept:
The operational cost created by continuous divergence between authorized state and actual execution state.
Part II — Hardware-Rooted Substrate Security
The software architecture can be strengthened by introducing hardware-backed trust.
The purpose of hardware is not to replace the authority layer.
Instead, hardware answers another question:
Can we trust the platform and execution environment on which the authorized workload is going to run?
The architecture becomes:
Authority
↓
Authorization
↓
Platform Trust
↓
Execution Gate
↓
Kernel Enforcement
↓
Workload
17. What Hardware Adds
Without hardware:
"Is this workload authorized?"
With hardware-backed trust:
"Is this workload authorized?"
+
"Is it running on an acceptable platform?"
This creates an additional trust dimension.
18. TPM as a Root of Trust
A TPM can provide a hardware-backed foundation for protected keys and platform measurements.
Conceptually:
Boot Component
↓
Measurement
↓
Kernel
↓
Measurement
↓
Runtime / Integrity Measurement
↓
TPM-backed state
↓
Attestation
The important distinction is:
Secure Boot
Only approved boot components may be loaded.
Measured Boot
Record what actually loaded so that it can be verified later.
Attestation
Provide verifiable evidence of the platform state to another party.
These mechanisms complement rather than replace the authorization service.
19. Hardware-Bound Authorization
The authorization receipt can now include platform requirements.
Conceptually:
{
"subject": "deployment-agent",
"action": "deploy",
"resource": "production-api",
"workload_digest": "sha256:ABC123",
"policy_version": "42",
"platform_requirements": {
"secure_boot": true,
"measurement_profile": "expected-profile",
"attestation_required": true
},
"expires_at": "...",
"signature": "..."
}
Now execution requires:
Valid Authority
+
Valid Workload
+
Valid Policy
+
Valid Platform Attestation
↓
Execution Allowed
This is substantially stronger than software-only authorization.
20. Hardware-Backed Zero Drift
Consider an approved environment:
Policy = v42
Workload = ABC123
Platform = Measurement M1
Now the platform changes:
Platform
↓
Measurement changes
↓
Attestation no longer matches
↓
Execution authorization fails
Likewise:
Binary changes
↓
Workload digest changes
↓
Authorization no longer matches
Or:
Policy changes
↓
Receipt becomes stale
↓
Reauthorization required
Drift therefore becomes a measurable property of the entire execution state rather than merely an application configuration problem.
21. Confidential Computing
A further layer can use hardware-supported confidential-computing technologies such as Intel TDX or AMD SEV-SNP.
These technologies can provide hardware-enforced isolation of confidential virtual machines and support attestation of the execution environment.
The architecture becomes:
HOST
│
│
┌───────▼────────┐
│ Confidential VM │
│ │
│ Linux │
│ Substrate Gate │
│ Landlock │
│ Seccomp │
│ Workload │
└───────┬────────┘
│
Attestation
│
▼
[Control Plan](/blog/control-plans-for-gcc-process-stability-3)e
The benefit is that part of the host/hypervisor environment can be moved outside the trusted computing boundary.
22. Full Hardware-Enhanced Architecture
HUMAN / AI / SERVICE
│
INTENT
│
▼
┌────────────────────┐
│ AUTHORITY / POLICY │
└──────────┬─────────┘
│
Signed Receipt
│
▼
┌────────────────────┐
│ PLATFORM TRUST │
│ │
│ Secure Boot │
│ Measured Boot │
│ TPM / Attestation │
└──────────┬─────────┘
│
Platform Verified
│
▼
┌────────────────────┐
│ SUBSTRATE GATE │
│ │
│ Receipt │
│ Workload │
│ Policy │
│ Platform │
│ Scope │
└──────────┬─────────┘
│
┌────────────┼────────────┐
▼ ▼ ▼
Landlock Seccomp no_new_privs
│ │ │
└────────────┼────────────┘
▼
Restricted Workload
│
▼
Audit / Attestation
│
▼
[Control Plan](/blog/control-plans-for-gcc-process-stability-3)e
23. The Three Security Decisions
The complete model can be understood through three questions.
Decision 1 — Authority
Who authorized this action?
Provided by:
Identity
Policy
Human approval
Organizational authority
Decision 2 — Platform
Can the execution environment be trusted?
Provided by:
Secure Boot
Measured Boot
TPM
Attestation
Confidential Computing
Decision 3 — Runtime
Can the workload perform anything outside its authorized scope?
Provided by:
Substrate Gate
Landlock
Seccomp
no_new_privs
Namespaces
Cgroups
Process supervision
The final execution decision is therefore:
AUTHORIZED
AND
PLATFORM TRUSTED
AND
WORKLOAD VERIFIED
AND
RUNTIME CONSTRAINED
↓
EXECUTE
Any critical condition fails:
DENY / TERMINATE / REAUTHORIZE
24. The Complete State Machine
┌───────────────┐
│ REQUESTED │
└───────┬───────┘
│
▼
┌───────────────┐
│ EVALUATING │
└───────┬───────┘
│
┌──────────┴──────────┐
│ │
DENY ALLOW
│ │
▼ ▼
REJECTED PLATFORM CHECK
│
┌────────┴────────┐
│ │
FAILURE PASS
│ │
▼ ▼
REJECTED WORKLOAD CHECK
│
┌────────┴────────┐
│ │
FAILURE PASS
│ │
▼ ▼
REJECTED BUILD CONTEXT
│
▼
EXECUTING
│
┌───────────────┼───────────────┐
│ │ │
SUCCESS EXPIRE VIOLATION
│ │ │
▼ ▼ ▼
COMPLETE STOP BLOCK
25. What Changes Between the Two Models?
| Capability | Software Substrate | Hardware-Enhanced Substrate |
|---|---|---|
| Intent | Yes | Yes |
| Authority | Yes | Yes |
| Signed receipt | Yes | Yes |
| Workload hash | Yes | Yes |
| Policy binding | Yes | Yes |
| Execution gate | Yes | Yes |
| Landlock | Yes | Yes |
| Seccomp | Yes | Yes |
no_new_privs | Yes | Yes |
| Platform integrity | Software assumptions | Hardware-backed measurements |
| Secure Boot | Optional | Strongly integrated |
| Attestation | Software/service level | Hardware-backed |
| Protected keys | Software/HSM options | TPM-backed |
| Confidential VM | No | Optional |
| Trust in host/hypervisor | Relatively high | Can be reduced |
| Assurance level | Strong software control | Stronger hardware-rooted control |
26. What Bare Metal Security Is — and Is Not
The model should not claim:
- that hardware makes systems invulnerable
- that software vulnerabilities disappear
- that patching becomes unnecessary
- that every CPU instruction becomes individually authorized
- that malicious code can never exist
Instead, the defensible claim is:
Security authorization is established before a protected workload enters its authorized execution state, and runtime capabilities are constrained independently of the workload's own application logic.
With hardware:
That authorization can additionally be conditioned on the integrity and attested state of the execution platform.
27. The Core Security Principle
The entire model can ultimately be reduced to:
INTENT
↓
AUTHORITY
↓
SIGNED RECEIPT
↓
PLATFORM TRUST
↓
WORKLOAD IDENTITY
↓
EXECUTION GATE
↓
KERNEL ENFORCEMENT
↓
EXECUTE
Traditional security primarily asks:
"Is the system behaving maliciously?"
The Substrate Security model asks an earlier question:
"Is this system authorized and trusted enough to enter this execution state?"
That is the central architectural shift.
28. Final Position
The software version is the practical starting point.
It can be implemented today using standard Linux primitives and tested without specialized hardware.
The hardware-enhanced version adds a stronger root of trust by binding authorization to platform integrity and, where appropriate, confidential execution.
The resulting architecture is therefore layered rather than dependent on a single technology:
Human / Organizational Authority
↓
Intent
↓
Authorization
↓
Hardware Platform Trust
↓
Substrate Execution Gate
↓
Linux Kernel Enforcement
┌───────┼────────┐
↓ ↓ ↓
Landlock Seccomp Privilege
↓
Workload
↓
Audit
The central thesis remains unchanged:
Move security from a predominantly reactive model of detecting bad execution toward a pre-execution model in which authority, trust and runtime constraints determine whether consequential execution is allowed to occur at all.
Comments
Be the first to comment on this post.
Sign in to leave a comment.