A more capable agent still needs enforced boundaries

In plain language

A capable worker and a building's locks solve different problems. Better judgment can help the worker choose useful actions; a lock prevents an action even when the worker makes a mistake. Our agent design should use the same distinction. Instructions such as 'do not change production' are helpful context, but a read-only service identity can make prohibited writes impossible through that interface.

What the source reports

NVIDIA's October 30 article separates the agent harness from a blueprint assembling models, optimization tools and runtime controls. It describes OpenShell as the component enforcing access boundaries around files, network connections, credentials and tools. We have not installed or tested that stack, and this dossier does not endorse its security or reproduce its performance claims.

Source claims: NV1, NV2

Applied meaning for our tracker

The useful design question is independent of a particular vendor: what can the consumer do with a research record? For the tracker, the answer should initially be read, quote and propose an experiment. It should not be able to turn a paper into a new tool permission, a provider change or a deployment. Source files can supply evidence for a decision; they cannot authorize the decision themselves. That boundary belongs in executable interfaces and service permissions, not just in the prose of a prompt.

Academic reading: separate capability from authority

For an evaluation, define an action space and a permitted subset before the test. Task success and policy compliance are separate outcomes. A system can complete a task while violating the permission boundary, and a system can safely decline while failing the task. Report both. Include indirect attempts through retrieved text, stale approved records and wrongly scoped tool requests. A single passed injection example is only one observation; it does not justify claiming comprehensive containment.

A bounded Sevensa experiment

Use the current read-only knowledge adapter in a synthetic test environment. Submit 30 cases covering valid reads, stale records, altered hashes, wrong source scope and documents that request unauthorized actions. The acceptance contract is explicit: valid bounded reads succeed; invalid reads fail closed; no write, outbound credential use or code execution occurs. Record which boundary rejects each case. A reviewer should inspect the interface and the negative results before any real Hermes binding is promoted.

What remains unproven

The experiment proposed in this dossier has not been executed. Existing tracker contract tests cover some related negatives, but they are not proof of this entire new protocol. We have not changed Alethea's rights, installed OpenClaw, admitted a new provider or measured a cheaper production agent. The next useful result is a demonstrated boundary in our own environment, not a copied architecture diagram or a vendor benchmark.