External authority → OpenShell runtime enforcement → verifiable evidence: a live AgentNOMOS integration

[AgentNOMOS]

Hi OpenShell maintainers,

we have completed a live integration of OpenShell into the AgentNOMOS Trust Chain and would value architectural feedback before taking it further.

The boundary we implemented is deliberately narrow:

• AgentNOMOS owns intent, policy, admission and authority.
• OpenShell owns runtime, sandbox and enforcement.
• AgentNOMOS binds the observed execution into evidence, receipt and outcome.

In short: AgentNOMOS decides whether an action may run. OpenShell enforces the runtime boundary. AgentNOMOS binds what actually happened into verifiable evidence.

What we actually built

This is not only a proposed architecture. We completed and froze a real OpenShell execution lineage and then integrated the resulting execution boundary into the live AgentNOMOS machine-readable Trust Chain under S7 — Execution / Delivery. OpenShell remains a scoped execution-boundary implementation inside S7; it does not create another top-level stage.

The resulting model records:

• AgentNOMOS as authority owner
• OpenShell as runtime-enforcement owner
• AgentNOMOS as evidence-binding owner
• bounded one-shot authority
• replay disabled
• execution/effect evidence bindings
• a separate post-execution verification pass
• explicit negative claims preventing the evidence from being overstated

The implementation has passed:

• 144/144 offline validator checks
• 166/166 live/public validator checks
• 55/55 guard checks
• 35/35 assurance checks
• 18/18 mutation checks
• 40/40 human ↔ machine consistency checks
• 6/6 frozen OpenShell evidence bindings
• 0 final post-deployment verification failures

Each public surface is byte-checked against its canonical local source, and the human-readable and machine-readable representations pass a 40/40 semantic consistency check.

Important scope boundary

We are intentionally not claiming that all current AgentNOMOS production executions run through OpenShell. The published OpenShell evidence applies only to our frozen R1_4I execution lineage.

We also do not claim TPM/TEE attestation, measured boot, host-independent trust, root-adversarial enforcement, NVIDIA certification, NVIDIA endorsement, or an NVIDIA partnership.

Our global public claim ceiling remains EXECUTION_BOUND_PROOF. The OpenShell-specific evidence class is scoped underneath that boundary rather than replacing it.

Why we think this may be useful upstream

During the integration we found that the interesting boundary is not simply "can an external system read OpenShell logs?" The harder question is:

Can an external governance system obtain authoritative OpenShell facts that it can safely bind to an external authorization and later to an outcome — without inventing associations that OpenShell itself did not establish?

This overlaps with #2661 and with the evidence-bundle design explored in #2745. We noticed that #2745 was ultimately closed as not planned, so we do not want to imply that it represents an active OpenShell roadmap direction.

What caught our attention, however, was how the design evolved in the discussion: a detached manifest.sig over the exact manifest bytes, per-sandbox metadata.sequence, and a three-valued completeness result — verified complete over the covered range, provable gap, or not established.

That distinction maps closely to how AgentNOMOS treats evidence boundaries: attribution is not verification, and absence of contradictory evidence must not silently become a positive proof.

From an external governance consumer's perspective, the most useful primitive would be a stable way to bind facts such as:

• immutable sandbox/workload identity
• the effective policy/configuration actually enforced
• the relevant policy/config revision
• a stable operation/execution identity
• the observed runtime-event interval
• completeness/incompleteness of that interval
• exact evidence bytes or digests
• resulting runtime/effect state where OpenShell can authoritatively provide it

AgentNOMOS can sign, store, correlate and expose those facts externally. An external layer may bind and sign facts it receives, but it must not manufacture authoritative relationships or completeness that the runtime itself has not established.

The architectural questions

We would appreciate maintainer feedback on three points:

1. Does this separation look correct?
   external authority → OpenShell runtime enforcement → external evidence/receipt
   In other words, should OpenShell remain authoritative only for the execution facts it actually enforces/observes, while an external governance layer remains responsible for business authorization and the broader evidence chain?

2. Is the evidence-bundle direction explored in feat(observability): export an atomic sandbox governance evidence bundle #2745 still something maintainers would consider useful for external governance consumers, despite that issue being closed as not planned?
   If not, which existing or intended OpenShell lifecycle/API boundary should external systems use to obtain authoritative execution facts without inventing associations or completeness claims themselves?

3. Would a minimal reference integration be useful?
   If the pattern is directionally useful, we would be happy to reduce our integration to a small vendor-neutral example or documentation contribution rather than proposing that OpenShell adopt the AgentNOMOS model itself.

Public implementation

• Repository: https://github.com/AgentNOMOS/AgentNOMOS
• S7 execution boundary: https://github.com/AgentNOMOS/AgentNOMOS/blob/main/docs/openshell-execution-boundary.md
• Technical brief: https://github.com/AgentNOMOS/AgentNOMOS/blob/main/docs/nvidia-openshell-technical-brief.md
• Live machine-readable Trust Chain: https://agentnomos.com/.well-known/nomos-capabilities.json
• Human verification: https://agentnomos.com/verify.html
• Reproducibility: https://agentnomos.com/.well-known/nomos-reproducibility.json

The goal of posting here is not to make a partnership claim or ask OpenShell to adopt our architecture. We would simply like to understand whether this external authority + OpenShell enforcement + external verifiable evidence boundary is useful to the project, and where maintainers would want that integration seam to live.

Thanks for any architectural feedback.

Murat Keskin
AgentNOMOS