Proposal: scope deployment acceptance, hardware evidence, delegation composition and standards mappings #64

Purpose: maintainer scope assessment, not a new delivery commitment

I 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.

This is an informative proposal. It adds no normative requirements, changes no conformance levels, and does not reopen parked hardware work.

Related ownership:

• Canonical composition tracker: Track confidentiality guarantees across model execution, tools and agent delegation #41.
• Existing acceptance harness: Build a reproducible acceptance harness for confidential workflows across components integrations#199.
• Measured application identity: Bind deployed broker code and effective configuration to appraised workload identity weight-custody-manifest#144.
• Parked hardware lifecycle acceptance: Parked: validate protected lifecycle time, storage, restart and erasure on a controlled host weight-custody-manifest#200.
• cA2A hardware conformance and release decision: tracker: complete confidential-hardware conformance and release assurance decision ca2a#47.

The 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.

1. First contribution: an explicit deployment acceptance profile

Question: What exact claim can a relying party accept after composing the existing manifest, gateway, delegation and evidence checks?

A proposed informative profile would identify:

• Assets, principals, authorized recipients, trusted components and all relevant effect paths.
• Required evidence and trust inputs: source/package/configuration pins, approved measurements, challenge binding, applicable platform policy and freshness/revocation inputs.
• Separate results for authorization, delivery, installation, execution and independently observed effects.
• Explicit unchecked requirements and unknown outcomes. Signature validity alone must not be described as full deployment acceptance.
• Change impact: which evidence must be repeated after code, policy, model/provider or platform changes.

Much 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.

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.

2. Hardware / bare-metal: conditional platform adapter and evidence profile

If an accountable operator and suitable host become available, investigate one existing isolation platform and one protected effect.

Distinguish these controls instead of treating “virtualization” as a complete guarantee:

Here “IP” means peripheral/accelerator hardware IP. Protection domains should follow distinct authority boundaries; a VM per ordinary thread is not the proposed feature.

AgenTrust'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.

The 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.

3. “Mesh LLM”: narrow to delegation composition

Use a second agent only after the single-boundary experiment is interpretable.

Candidate tests:

• Delegation cannot amplify the principal's authority.
• Untrusted content is not promoted into authority merely by crossing an agent boundary.
• Request/response authentication, replay handling, revocation and timeout outcomes retain their precise meanings.
• Evidence links identify what was actually checked at each hop.

A 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.

4. Standards: informative evidence crosswalk

Consider a small versioned mapping from a selected assurance/risk framework to:

1. Evidence AgenTrust can supply.
2. Additional deployment or organizational controls.
3. The assessor/owner responsible for acceptance.
4. Known omissions and change triggers.

NIST 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.

Scope basis and research limits

The proposed boundary follows the published charters:

• Agent Manifest: identity/provenance and verification; runtime policy enforcement excluded.
• cMCP: tool-call enforcement; general network policy and model governance beyond that boundary excluded.
• cA2A: confidential delegation profile, not replacement transport or general model governance.
• TRACE: execution evidence; runtime policy engines and hardware side-channel mitigation excluded.
• WCM: custody; fixing the hardware layer excluded.

The 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.

Decisions requested

1. Is the acceptance-profile work useful within Track confidentiality guarantees across model execution, tools and agent delegation #41/#199, or already sufficiently covered?
2. Should hardware/IP isolation remain an external deployment dependency with an informative adapter profile?
3. Is a bounded two-agent delegation-composition experiment welcome, and which repository should own it?
4. Would an informative standards crosswalk be useful, and which assessed object/framework should it target?

I suggest selecting one software contribution first, then opening or extending component tasks only after scope and ownership are agreed.