Can the agent execution stack be governed independently of its own assertions?

[ljefford2-cmyk]

Architectural question: Can the agent execution stack be governed independently of its own assertions?

I am an independent end user and operator working on a technology-neutral governance architecture for AI-mediated operations. I have been following NVIDIA’s work around agentic systems, including NemoClaw and OpenShell, and I would like to ask a fairly direct architectural question.

Can an external governing system sit above this stack without depending upon the governed components to certify their own correctness?

More specifically:

• Can an independent governing layer witness what actually crossed the effect boundary, rather than relying solely on logs or assertions produced by the components responsible for the action?
• Can authority be denied or revoked independently of the model, agent runtime, OpenShell, operating system, and other components participating in execution?
• Can the complete execution path be reconstructed from proposal through authorization, dispatch, and actual effect using evidence whose validity does not depend solely upon the acting components?
• Can individual components — OpenShell, NemoClaw, the operating system, CUDA, models, agent runtimes, or eventually the hardware platform — be replaced without changing the governing invariant?
• What interfaces, evidence surfaces, enforcement points, revocation mechanisms, and external observability capabilities exist to make that independence possible?

The larger reason for asking is this:

We are trying to determine whether this architecture supports independent governance of the complete AI-mediated execution environment, rather than governance that ultimately depends upon the governed stack’s own assertions.

I do not think AI or its agents can be adequately governed by evaluating individual controls in isolation.

Sandboxing may work correctly. Identity may work correctly. Policy enforcement may work correctly. The model may behave correctly. The operating system may work correctly. Audit logging may work correctly.

But none of those facts, individually, establishes that the resulting machine action was authorized and correctly executed.

At the system level, I believe we eventually have to be able to independently evaluate and reconcile:

what was authorized → what the system intended → what was dispatched → what actually occurred → what evidence remains afterward

That distinction becomes increasingly important as agentic systems span models, runtimes, operating systems, local and cloud resources, tools, external services, and physical or institutional effects.

I am not asking NVIDIA, the maintainers, or the community to validate our architecture. Nor am I suggesting that NemoClaw or OpenShell should themselves solve every part of this problem.

I am trying to understand something more fundamental:

Where does the boundary of their responsibility end, what evidence and control surfaces do they expose at that boundary, and can an independent governing architecture remain genuinely independent while the underlying AI execution stack changes?

I would appreciate technical correction if I have misunderstood the architecture. I would also be interested in pointers to existing interfaces, documentation, design decisions, or work already addressing these questions.

— Lawrence S. Jeffords
Independent End User / Operator

[antagoninc]

I think the answer is yes, but only with a carefully defined trust boundary. OpenShell provides several enforcement mechanisms that an independent governance system can build upon. Those mechanisms should not, however, be confused with independent proof of the complete execution outcome.

The distinction I would make is between policy enforcement, authorization evidence, and independently verified effects.

1. What OpenShell already provides

According to the current [OpenShell security documentation](https://docs.nvidia.com/openshell/dev/security/best-practices), the runtime has enforcement surfaces at several layers:

• Network egress through a policy-enforcing proxy.
• Filesystem restrictions through Landlock.
• Process restrictions through seccomp and privilege controls.
• Provider-credential access through endpoint-bound controls.
• Runtime network-policy updates and associated audit events.

These are valuable enforcement mechanisms. Importantly, they operate outside the model's ordinary reasoning process.

However, an enforcement log establishes what a particular control observed or decided, not necessarily the final effect of an operation.

For example, allowing an HTTPS request does not independently prove that the intended transaction committed, that its parameters remained unchanged, or that the receiving system applied the expected state transition.

2. Independent governance requires an external authority boundary

I would separate the architecture into:

External authority → enforcement boundary → execution → independent evidence collection → reconciliation.

The external authority should establish:

• Which principal is authorized.
• Which exact action and parameters are permitted.
• Which target resources may be affected.
• The authorization's lifetime and applicable policy version.
• The conditions under which authority is revoked.

OpenShell can enforce relevant sandbox and network restrictions, but application-specific authorization may still require an additional gate at the tool or receiving-service boundary.

Revocation must also account for already-dispatched or in-flight operations. Preventing future requests does not undo effects that have already committed.

3. Reconstructing the execution chain

I would use separately identifiable evidence for five stages:

1. Proposal: Canonical representation and digest of the requested action.
2. Authorization: Signed decision bound to that action digest, principal, policy version, and validity window.
3. Dispatch: Evidence identifying the action actually submitted to the execution boundary.
4. Effect: A receipt or state observation from the authoritative receiving system.
5. Reconciliation: An independent comparison of authorized intent, dispatched action, and observed outcome.

The evidence should distinguish AUTHORIZED, DISPATCHED, COMMITTED, REJECTED, and UNKNOWN. Missing execution evidence must never be silently promoted to success.

Where appropriate, signed receipts, content-addressed artifacts, trusted timestamps, and append-only evidence storage can support later verification.

However, a signed assertion from a compromised component remains an assertion from that component. Cryptographic integrity alone does not establish that its underlying observation was truthful.

4. Component replacement and trust independence

To preserve the governing invariant as components change, define a technology-neutral evidence and enforcement contract.

A replacement runtime should have to demonstrate that it preserves:

• Complete mediation of relevant effect paths.
• Identity-to-action authorization binding.
• Revocation and replay controls.
• Evidence integrity and provenance.
• Independent observation or confirmation of external effects.
• Explicit failure behavior when enforcement or evidence collection is unavailable.

Hardware attestation or confidential execution can strengthen claims about the measured software and its environment, but they do not independently prove external business outcomes.

5. What I would test

Before claiming independent governance, I would run adversarial tests covering:

• Authorized action with mutated parameters.
• Revocation before dispatch.
• Revocation racing with an in-flight operation.
• Duplicate execution and replay.
• Missing or forged execution receipts.
• Compromised or unavailable evidence collector.
• Sandbox escape or bypass of a relevant enforcement point.
• A receiving service reporting a result inconsistent with its authoritative state.

Each test should verify both the enforcement decision and the actual observed effects.

Conclusion

My reading is that OpenShell can serve as a strong enforcement component in an independent governance architecture, but it should not be treated as the sole authority over whether an operation was correctly executed.

For the maintainers, the specific interfaces I would be interested in are:

1. A stable mechanism for exporting policy decisions and their identifiers.
2. Evidence of which policy revision was actually active at enforcement time.
3. Supported external policy-update and revocation interfaces.
4. A way to correlate enforcement events with externally verified action receipts.
5. Documentation of the enforcement boundary's limitations and possible bypass paths.

That would make it possible to evaluate OpenShell as one replaceable component in a larger, independently verifiable execution system without requiring OpenShell itself to solve end-to-end governance.

[ljefford2-cmyk]

Thank you for the detailed response. Your distinction between policy enforcement, authorization evidence, and independently verified effects is helpful.

Let me make the organizational concern behind my question clearer. An action can satisfy the sandbox’s rules and execute exactly as requested while still being wrong for the organization. For example, a payment could be permitted and successfully processed even though the same invoice had already been paid through another system.

Determining whether that operation was correct requires evidence from across the process: what the organization intended to accomplish, what authority and information were valid at the time, what was actually done, and what result followed. That broader evaluation must establish whether the action remained appropriate to the organization’s mission and current circumstances.

My practical question is what OpenShell currently makes available to support that evaluation. What can an outside observer collect and check about the requests OpenShell received, the policies and decisions actually applied, and the actions it sent onward?

How can those records be connected with authorization and evidence from other systems? Where does visibility end, and which conclusions would still depend entirely on OpenShell’s own reporting?

Pointers to existing interfaces and their documented limitations would help establish what OpenShell contributes to the overall evidence and where additional independent observation is needed.

Thank you for the reply!

[antagoninc]

Thanks for clarifying. I agree that the relevant question is not merely whether OpenShell enforces a sandbox policy, but what evidence an independent evaluator can obtain from OpenShell and reliably reconcile with the rest of an organization's operation.

I reviewed NVIDIA's current OpenShell v0.1.7 observability and policy documentation. There are several concrete interfaces available, although their coverage and retention limits matter.

1. What OpenShell currently reports

OpenShell emits Open Cybersecurity Schema Framework (OCSF) v1.8.0 events covering network, HTTP, process, authentication, configuration, lifecycle, and security-finding activity.

The documented event classes include:

• NET: — connection attempts, allow/deny decisions, destinations, processes, and policy rules.
• HTTP: — HTTP method, target, and request-level enforcement outcomes.
• PROC: — process lifecycle observations.
• CONFIG: — policy loading, reloading, and configuration changes.
• AUTH: and API: — selected authentication and gateway authorization events.
• FINDING: — reported security findings, including certain replay and bypass detections.

For example, the documentation shows an allowed network event containing the executable, process ID, destination, policy rule, and enforcement engine.

Middleware events can also indicate whether a request was transformed, using fields such as transformed:true.

Important limitation: These records identify what the relevant enforcement component observed. They are not necessarily complete copies of the incoming and outgoing application payloads. A transformation flag does not independently establish the exact before-and-after content.

A permitted connection or HTTP request also does not establish that the receiving system committed an intended operation.

Documentation: [Sandbox Logging](https://docs.nvidia.com/openshell/latest/observability/logging)

2. Which policy was actually active

OpenShell exposes both policy inspection and revision information:

openshell policy get my-sandbox --full
openshell policy list my-sandbox

The first returns the effective policy, including provider-composed rules. The second shows revisions and whether they were loaded by the sandbox.

The logs also contain configuration events, including policy-load events with a policy hash and configuration-change events with revision information.

A particularly important distinction in the documentation is that gateway acceptance of a new policy does not necessarily mean it became active. The sandbox must load the revision successfully.

For historical evaluation, I would capture the effective policy artifact and its hash at the time of execution, together with the loaded revision and corresponding configuration events.

I would not treat a later policy snapshot as proof of which rules governed an earlier request.

Documentation: [Manage Sandbox Policies](https://docs.nvidia.com/openshell/latest/how-it-works/policies/manage-policies)

3. How an independent witness can collect the evidence

There are several documented collection interfaces.

Human-readable logs:

openshell logs my-sandbox --source sandbox

Machine-readable OCSF export:

openshell settings set my-sandbox \
  --key ocsf_json_enabled --value true

Supervisor-originated OCSF records can then be collected as JSON output or JSONL files through the supervisor's container/runtime logging interfaces.

OpenShell also supports gateway-side OCSF JSONL collection and OTLP export to external collectors.

A machine-readable record can include:

• metadata.uid — the individual event identifier.
• container.uid — the associated sandbox identity, when present.
• Event timestamp, classification, status, and action.
• Process and network endpoint information.
• Relevant policy-rule context.

These provide useful reconciliation keys, but an event UID is not automatically an organizational operation ID.

An independent collector should ingest these events outside the agent's control, preserve the original records, and bind the collected evidence to the applicable runtime and policy configuration.

Documentation: [OCSF JSON Export](https://docs.nvidia.com/openshell/latest/observability/ocsf-json-export)

4. Connecting OpenShell evidence to authorization and external results

I would use three evidence sources:

Authorization system: Establishes who was authorized, the exact action, relevant policy and authority version, and any expiration or revocation constraints.

OpenShell: Reports observed enforcement activity, policy decisions, configuration state, and relevant runtime events.

Receiving system or independent observer: Establishes what was actually committed, rejected, changed, or left unresolved.

For reliable reconciliation, the trusted application boundary should introduce an operation identifier and canonical action digest before dispatch.

Those identifiers should be carried into the authorization evidence and, where supported, the downstream execution receipt. OpenShell's sandbox and event identifiers can then help associate relevant enforcement observations.

However, I would not assume OpenShell automatically propagates an application-level authorization identifier into every event. That requires an explicit integration and a verified correlation path.

This also means that an ALLOWED event alone should never be promoted into an assertion that the authorized business action succeeded.

5. What remains unobserved or potentially incomplete

This is an especially important limitation documented by NVIDIA.

The gateway's recent-log buffer is bounded and nonpersistent. Events can be dropped under load or disconnection.

The openshell logs watch stream supports resumable cursors and can signal skipped events or an unrecoverable OUT_OF_RANGE gap. Those mechanisms help detect some collection failures but do not guarantee complete observation.

There is also a collection boundary between the supervisor and the workload:

• Supervisor enforcement events have their own collection paths.
• Certain sandbox-runtime events, including process-launch and Landlock information, appear in workload container logs instead.
• Main process output and interactive execution output can have separate visibility limitations.

The JSON/OTLP exporters are also best-effort. They have bounded queues, drop/error metrics, and some gap reporting, but they do not establish a lossless, cryptographically complete execution history.

An external evaluator therefore needs to retain collection-health evidence and represent unresolved gaps explicitly.

Documentation: [Accessing Logs and Loss Awareness](https://docs.nvidia.com/openshell/latest/observability/accessing-logs)

6. The organizational question remains separate

Your example of an action duplicating work already completed elsewhere illustrates the distinction well.

OpenShell might correctly permit an operation under its sandbox policy while the broader organization should reject it because:

• The objective has already been satisfied.
• The authority has changed or been revoked.
• The operation is no longer necessary.
• Current conditions make execution inappropriate.
• The expected effects would conflict with another system's state.

Those questions require information that may be outside OpenShell's observation and policy scope.

An independent organizational evaluator needs to reconcile authorization, current mission or task state, OpenShell enforcement evidence, and authoritative execution outcomes.

Conclusion

My assessment is that OpenShell currently contributes useful, structured evidence about its enforcement boundary, but not a complete independently verifiable account of organizational action and outcome.

It provides an important part of the evidence chain, not the entire chain.

A useful next experiment would be a controlled state-changing operation with:

1. An externally recorded authorization and operation ID.
2. Captured OpenShell OCSF records and active-policy revision.
3. An independently issued receiving-system receipt.
4. A negative test involving changed parameters or revoked authorization.
5. A simulated logging interruption to evaluate what the independent witness can detect.

The resulting evidence package could establish precisely which assertions are supported by OpenShell, which are supported by external observers, and which remain indeterminate.

That would be a valuable, reproducible basis for evaluating OpenShell's role in a larger independent governance system.

I'd be particularly interested in whether the maintainers recommend an existing application-level correlation mechanism for linking an external authorization ID to OCSF enforcement records, beyond the documented sandbox/event identifiers and available tracing context.