René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Proposal: scope deployment acceptance, hardware evidence, delegation composition and standards mappings","articleBody":"## Purpose: maintainer scope assessment, not a new delivery commitment\n\nI would like feedback on three possible contribution directions: hardware/bare-metal evidence, multi-agent delegation composition, and standards-informed evidence mappings. After reviewing the component charters, I think these should be narrowed to **deployment evidence and acceptance**, rather than adopted as a broad AI safety platform roadmap.\n\nThis is an informative proposal. It adds no normative requirements, changes no conformance levels, and does not reopen parked hardware work.\n\nRelated ownership:\n- Canonical composition tracker: #41.\n- Existing acceptance harness: agentrust-io/integrations#199.\n- Measured application identity: agentrust-io/weight-custody-manifest#144.\n- Parked hardware lifecycle acceptance: agentrust-io/weight-custody-manifest#200.\n- cA2A hardware conformance and release decision: agentrust-io/ca2a#47.\n\nThe latest comment on #41 favors narrowing current work to software composition. This proposal respects that direction; accepted implementation work should remain in the existing owners, not become a competing backlog here.\n\n## 1. First contribution: an explicit deployment acceptance profile\n\n**Question:** What exact claim can a relying party accept after composing the existing manifest, gateway, delegation and evidence checks?\n\nA proposed informative profile would identify:\n\n- Assets, principals, authorized recipients, trusted components and all relevant effect paths.\n- Required evidence and trust inputs: source/package/configuration pins, approved measurements, challenge binding, applicable platform policy and freshness/revocation inputs.\n- Separate results for authorization, delivery, installation, execution and independently observed effects.\n- Explicit unchecked requirements and unknown outcomes. Signature validity alone must not be described as full deployment acceptance.\n- Change impact: which evidence must be repeated after code, policy, model/provider or platform changes.\n\nMuch of this already appears in #199. The contribution would be to reconcile and make its existing acceptance procedure reusable, not claim a missing feature or introduce another universal verdict API.\n\n**Smallest demonstration:** deterministic synthetic worker, one permitted operation and one independently observed target. Include a valid positive control and paired substitution, downgrade, replay, bypass, revocation and interrupted-outcome controls, with deliberate gate weakening where applicable. No live LLM is necessary to test the authorization invariant. Software results remain software results; #199's full acceptance stays open until its own criteria are met.\n\n## 2. Hardware / bare-metal: conditional platform adapter and evidence profile\n\nIf an accountable operator and suitable host become available, investigate one existing isolation platform and one protected effect.\n\nDistinguish these controls instead of treating “virtualization” as a complete guarantee:\n\n| Boundary | Platform responsibility to document |\n|---|---|\n| CPU memory | Process/VM/MPU/PMP/capability domain and privilege/context-switch assumptions |\n| Device DMA | IOMMU/SMMU/IOPMP or equivalent enforced mappings and requester identity |\n| Peripheral or accelerator registers | MMIO permissions, protected configuration and target-side access controls |\n| Command semantics | Trusted broker/driver validates operations, parameters and current authority |\n| Lifecycle | Queue quiescence, mapping invalidation, reset, stale authority and residual data |\n\nHere “IP” means peripheral/accelerator hardware IP. Protection domains should follow distinct authority boundaries; a VM per ordinary thread is not the proposed feature.\n\nAgenTrust's possible contribution is binding/appraising the relevant platform and broker evidence, documenting assumptions, and reproducing one bypass attempt against independent effect observations. Developing a hypervisor, SoC firewall, TEE SDK or new silicon is not proposed as core scope.\n\nThe software profile can document these prerequisites now. Hardware execution remains conditional. WCM #200 retains all seven existing acceptance criteria; this smaller experiment would not by itself close it, establish secure erasure, or restore protected-execution work previously closed as not planned. No hardware availability, no-cost eligibility or funding is established.\n\n## 3. “Mesh LLM”: narrow to delegation composition\n\nUse a second agent only after the single-boundary experiment is interpretable.\n\nCandidate tests:\n- Delegation cannot amplify the principal's authority.\n- Untrusted content is not promoted into authority merely by crossing an agent boundary.\n- Request/response authentication, replay handling, revocation and timeout outcomes retain their precise meanings.\n- Evidence links identify what was actually checked at each hop.\n\nA delegation graph does not itself establish exactly-once effects, a global spending ceiling, distributed consensus or truthful model outputs. Shared invariants need an explicitly owned ledger/coordination or rights-allocation mechanism. General orchestration, model sharding and distributed inference are separate topics.\n\n## 4. Standards: informative evidence crosswalk\n\nConsider a small versioned mapping from a selected assurance/risk framework to:\n1. Evidence AgenTrust can supply.\n2. Additional deployment or organizational controls.\n3. The assessor/owner responsible for acceptance.\n4. Known omissions and change triggers.\n\nNIST AI RMF, ISO/IEC 23894 and assurance-case approaches are candidate references, pending selection and access to the necessary text. This would be guidance, not clause-level conformity, organizational certification, legal advice or a claim of “certified safe AI.” Sector-specific physical safety remains outside this generic profile.\n\n## Scope basis and research limits\n\nThe proposed boundary follows the published charters:\n- [Agent Manifest](https://github.com/agentrust-io/agent-manifest/blob/main/CHARTER.md): identity/provenance and verification; runtime policy enforcement excluded.\n- [cMCP](https://github.com/agentrust-io/cmcp/blob/main/CHARTER.md): tool-call enforcement; general network policy and model governance beyond that boundary excluded.\n- [cA2A](https://github.com/agentrust-io/ca2a/blob/main/CHARTER.md): confidential delegation profile, not replacement transport or general model governance.\n- [TRACE](https://github.com/agentrust-io/trace-spec/blob/main/CHARTER.md): execution evidence; runtime policy engines and hardware side-channel mitigation excluded.\n- [WCM](https://github.com/agentrust-io/weight-custody-manifest/blob/main/CHARTER.md): custody; fixing the hardware layer excluded.\n\nThe background literature work is a scoping review of papers, standards summaries and platform documentation. It is not a systematic review, established novelty result, reproduced experiment or validated architecture. These are candidate contributions for assessment.\n\n## Decisions requested\n\n1. Is the acceptance-profile work useful within #41/#199, or already sufficiently covered?\n2. Should hardware/IP isolation remain an external deployment dependency with an informative adapter profile?\n3. Is a bounded two-agent delegation-composition experiment welcome, and which repository should own it?\n4. Would an informative standards crosswalk be useful, and which assessed object/framework should it target?\n\nI suggest selecting **one software contribution first**, then opening or extending component tasks only after scope and ownership are agreed.","author":{"url":"https://github.com/dinakarjs","@type":"Person","name":"dinakarjs"},"datePublished":"2026-10-16T18:09:15Z","url":"https://github.com/agentrust-io/.github/issues/64"}