Re: Re: Subject: Re: [AIW Submission] Neutral Trust Infrastructure (NTI)

Hi Chris (AlgoVoi),

This is one of the best peer reviews I have ever received. You are 100%
correct on every single point. These are exactly the precision gaps that
separate a whitepaper from an implementable standard.

I am adopting your feedback into the NTI-1 spec today:

1. Preimage defense: I will add strict RFC 8785 (JCS) canonicalization and
field ordering.
2. Granularity: We will explicitly separate the "Append-only hash chain"
(audit log) from the "Merkle accumulator" (revocation registry).
3. Trust Leases: I will add a terminal REVOKED state to the LGD state
machine and define lease renewal semantics.
4. Level 1 Governance: I will fix the logic so Level 1 does not omit Pillar
2. An audit-only profile will be explicitly named as such.
5. Test Suite: I will add the missing tamper detection and Byzantine
behavior test cases.
6. Governance: You are right that routing certification through the same
foundation reads as self-certification. I will separate the NTI Foundation
(Spec Steward) from the NTI Certification Authority (NCA).
7. EU Law & SOC2: I will soften the phrasing to present Article 8(2) as
motivation for audit records rather than a strict cryptographic
requirement, and clarify the SOC2 attestation boundary.

Thank you for the broken crates.io link catch as well—fixing that now.

And yes, I would absolutely love to include your shared test vectors for
preimage reproducibility and tamper detection. That would make the standard
bulletproof.

Best,
Abisheak


On Fri, 30 Oct, 2026, 7:41 am Abisheak P, <abisheakp197@gmail.com> wrote:

> Hi Larry,
>
> This is incredible. Thank you for reproducing the Aicent Stack's runner
> and for drafting the Rust regression cases.
>
> To confirm your evaluation parameters:
>
> · Commit Hash: 308fd1c95f2c2f975e8b6b6c5e7ccba0e4d7b203
> · Runnable Sidecar: NTIGuardrailMiddleware in the crewai-nti /
> Neutral-Trust-Infrastructure repo.
> · PAUSE-Receipt Entry Point: verify_tool_execution() (which triggers the
> incomplete_check fail-closed logic).
>
> AlgoVoi just provided a phenomenal review that will tighten the spec
> before we run your matrix. I am patching those exact definitions now.
>
> I am on board for a working session. I am flexible this week—let me know
> what time works for you (Chicago time) and I will be there.
>
> Best,
> Abisheak
>
>
> On Fri, 30 Oct, 2026, 6:53 am Larry Lewis, <llewis@sovrlabs.com> wrote:
>
>> Hi Abisheak,
>>
>> I’ve completed the first-pass matrix and reproduced Lee / Aicent Stack’s
>> independent lease-revocation runner for revisions 2 and 3. Both matched
>> their frozen baselines. We can build on that coverage as we prepare the
>> live runtime tests.
>>
>> I’ve also prepared two Rust regression cases against ube-foundation
>> commit 308fd1c95f2c2f975e8b6b6c5e7ccba0e4d7b203: whether an unsigned
>> capability token is rejected, and whether a configured quorum of two
>> prevents execution when only one eligible module is available.
>>
>> These are source-review hypotheses for us to examine together. The test
>> file passes the formatter check, but compilation is blocked here by the
>> available Cargo version and dependency access, so I’m not reporting Rust
>> test verdicts.
>>
>> Please confirm the runnable sidecar and PAUSE-receipt entry point, and
>> whether this is the commit you want evaluated. We can then agree on the
>> intended behavior and run the cases in a compatible environment.
>>
>> For the long-running-call test, let’s coordinate the operation contract,
>> registry failure behavior, and independent resource log, then bring the
>> reviewed evidence back to the group together.
>>
>> I’m on Chicago time and ready to arrange a working session.
>>
>> Best regards,
>> Larry Lewis
>> Founder, SovrLabs
>> Chair, W3C Agent Trust Protoco
>>
>>
>>
>> From: Abisheak P <abisheakp197@gmail.com>
>> To: "Steven Zhao"<zhaoxinghua07@126.com>
>> Cc: "Alan Karp"<alanhkarp@gmail.com>, <public-agentprotocol@w3.org>
>> Date: Wed, 28 Oct 2026 07:34:01 -0500
>> Subject: Re: Re: Subject: Re: [AIW Submission] Neutral Trust
>> Infrastructure (NTI)
>>
>> Hi Steven, Alan,
>>
>> Steven, you hit the exact "harder half" of the problem. HDP and ZCAP
>> handle state at the boundary, but they cannot stop a live chain
>> mid-execution when intent drifts.
>>
>> To answer your questions directly:
>>
>> 1. Pause/Halt: NTI operates as a sidecar. It maintains a live connection
>> to the Trust Engine. A human or policy layer can trigger a pause, and the
>> sidecar intercepts the next agent loop and fails closed.
>> 2. Revocation: We use a Merkle-chained Revocation Registry. If a token is
>> revoked, the root hash updates. The sidecar checks the proof against the
>> latest root hash before every tool call. It doesn't matter if the token was
>> issued 5 hops ago.
>> 3. Key Management (Alan's point): The agent never holds the private key.
>> The Dilithium5 keys are isolated in the Rust core.
>>
>> To stop this thread from becoming an endless theoretical debate, I have
>> published the full NTI paper online. It details the runtime enforcement
>> model, the key isolation, and how it integrates with HDP and ZCAP.
>>
>> 👉 Read the paper here:
>> https://github.com/abisheakp197/nti-spec/blob/main/AIW_Paper_NTI.md
>>
>> I look forward to the AIW session notes on Nov 6th.
>>
>> Best,
>> Abisheak
>>
>>
>> On Wed, 28 Oct, 2026, 11:48 am Steven Zhao, <zhaoxinghua07@126.com>
>> wrote:
>>
>> Hi Abisheak, Alan, all,
>>
>> Thanks both for the thread — this is exactly the discussion I was hoping
>> Topic 2 would spark. Alan's pointer to the HDP draft is useful, and
>> Abisheak's framing of audit (HDP) vs. execution-time enforcement (NTI) maps
>> cleanly onto the OAuth / ZCap / UCAN stack that Alan knows well.
>>
>> I'd like to flag one gap that this conversation — valuable as it is —
>> hasn't yet touched, and that sits at the heart of my Topic 2.
>>
>> Both layers described so far operate at the granularity of a single tool
>> call: HDP records it after the fact, NTI signs and blocks it at the
>> boundary. But neither addresses what happens *between* calls, once a
>> chain is already running:
>>
>>    - How does a human or a policy layer *pause* a long-running chain
>>    mid-execution — not deny the next call, but suspend the agent that's
>>    already mid-task?
>>    - How do you *halt* it when intent drifts from the original mandate,
>>    before the next tool call fires?
>>    - What does *revocation* look like for capability tokens that have
>>    already been issued and are being spent across multiple hops — not "don't
>>    issue the next one," but "revoke the ones already in flight"?
>>
>> Audit trails and enforcement gates answer "did the right thing happen,
>> and did we block the wrong thing." They don't answer "how do we stop it
>> once it's already underway." That runtime revocation — pause, halt,
>> kill-switch semantics for a live agent chain — is the harder half of
>> "revocable authority," and I'd be curious how the NTI model, the HDP model,
>> and the ZCap/UCAN lineage each plan to address it.
>>
>> On the process point: I won't be at AIW #3 in person (Beijing), so I
>> won't be pointing people at the leaderboard on Nov 6. If anyone on this
>> list is attending the opening circle, the ask in my original post still
>> stands — happy to have either topic raised, and to follow up on session
>> notes afterward.
>>
>> Best regards,
>>
>> Xinghua Zhao
>>
>> Independent researcher (SynomosAI initiative)
>>
>> ORCID: 0009-0001-0512-1237
>>
>> [Disclosure: drafting of this message was assisted by AI; all positions
>> reviewed and approved by me.]
>>
>>
>>
>>
>>
>>
>>
>> At 2026-10-28 01:08:29, "Alan Karp" <alanhkarp@gmail.com> wrote:
>>
>> There is also the issue of the agent proxying requests for agents not
>> authorized to make the requests themselves.  The sidecar gives you a place
>> to stand to at least figure out that happened.
>>
>> --------------
>> Alan Karp
>>
>>
>> On Tue, Oct 27, 2026 at 9:59 AM Abisheak P <abisheakp197@gmail.com>
>> wrote:
>>
>> Hi Alan,
>>
>> You hit the nail on the head. This is the exact threat model NTI was
>> built to solve. Agents are indeed terrible at keeping secrets, especially
>> with indirect prompt injection being a primary attack vector.
>>
>> If the private key lives inside the agent's context window or environment
>> variables, the system is already compromised.
>>
>> This is why NTI operates on a zero-trust sidecar architecture:
>>
>> 1. The agent never holds the secret. The Dilithium5 private key is stored
>> in an isolated Rust core (the TrustEngine), outside the LLM's execution
>> environment.
>> 2. Middleware Interception: When the agent wants to call a tool, the
>> NTIGuardrailMiddleware intercepts the request. The Rust core verifies the
>> agent's capability bounds, signs the payload, and executes the handoff. The
>> agent only receives the signed receipt, never the key.
>> 3. Capability-Based Tokens: Drawing from the object-capability model
>> you've championed, the agent is issued a single-use, cryptographically
>> bound token (attenuated to the specific tool), rather than raw access.
>>
>> You are absolutely right that this requires additional infrastructure. A
>> standard alone isn't enough; it requires a policy engine and a secure
>> enclave to manage the keys. That is the core of the NTI reference
>> implementation we are building.
>>
>> I would love to include your perspective on capability-based security in
>> the NTI section of the AIW Book of Proceedings. If you have time to review
>> the nti-spec repo, I would be honored to have your feedback on the
>> key-management model.
>>
>> Best,
>> Abisheak
>>
>> On Tue, 27 Oct, 2026, 9:40 pm Alan Karp, <alanhkarp@gmail.com> wrote:
>>
>> Cryptographic non-repudiation is a laudable goal, but agents are
>> notoriously bad at keeping secrets.  Do you need some additional
>> infrastructure to ensure agents aren't sharing secret keys?
>>
>> --------------
>> Alan Karp
>>
>>
>> On Tue, Oct 27, 2026 at 9:04 AM Abisheak P <abisheakp197@gmail.com>
>> wrote:
>>
>> Hi Alan,
>>
>> Thank you for the clarification. That makes perfect sense.
>>
>> This distinction—audit vs. enforcement—is exactly the gap NTI is designed
>> to fill. As you noted, OAuth and UCAN handle access control, and HDP
>> provides the audit trail. But neither enforces cryptographic
>> non-repudiation at the execution boundary (e.g., AI agents calling tools or
>> handing off tasks).
>>
>> In the NTI architecture, we don't try to replace HDP or UCAN. We act as
>> the fail-closed cryptographic bouncer. NTI wraps the execution loop,
>> verifies the post-quantum (Dilithium5) signature of the request, and then
>> generates the audit trail (which could easily be formatted as HDP metadata
>> or an HDP token).
>>
>> If OAuth is the ID check at the door, and HDP is the security camera
>> recording what happens inside, NTI is the physical lock on the vault that
>> won't open without the right cryptographic key.
>>
>> I will be sure to highlight this synthesis—HDP for audit, NTI for
>> post-quantum execution-time enforcement—in my paper for the AIW Book of
>> Proceedings.
>>
>> Best,
>> Abisheak
>>
>>
>> On Tue, 27 Oct, 2026, 9:30 pm Alan Karp, <alanhkarp@gmail.com> wrote:
>>
>> You correctly summarized HDP.  It is intended as an audit framework for
>> access control mechanisms that don't have a place for audit information,
>> such as OAuth.  Other systems, such as zcaps and UCAN only need to add a
>> few pieces of metadata to include the audit function of HDP with their
>> native access controls.
>>
>> --------------
>> Alan Karp
>>
>>
>> On Tue, Oct 27, 2026 at 8:11 AM Abisheak P <abisheakp197@gmail.com>
>> wrote:
>>
>> Hi Alan,
>>
>> Thank you for the reply and for sharing Asiri Dalugoda's HDP draft. I
>> just read through it. It's an excellent, highly rigorous piece of work,
>> particularly the append-only, offline-verifiable chain-of-custody mechanism.
>>
>> However, reviewing it against the NTI framework I submitted highlights
>> exactly why we need a layered approach for the Agentic Web:
>>
>> 1. Audit vs. Enforcement:
>> In Section 1.1 of the HDP draft, it explicitly states: "HDP is not an
>> authorization protocol... An HDP token MUST NOT be used as an input to any
>> access decision." It is a post-incident audit trail.
>> NTI is an active, fail-closed execution layer. We intercept the tool call
>> and block it if the signature is invalid. Enterprise CISOs cannot deploy
>> agents with just an audit log; they need prevention at the execution
>> boundary.
>>
>> 2. Classical vs. Post-Quantum:
>> HDP relies on Ed25519. While standard today, it is vulnerable to
>> Store-Now-Decrypt-Later attacks. NTI uses Dilithium5 (ML-DSA) to ensure the
>> delegation chain survives the quantum transition.
>>
>> I actually see these protocols as highly complementary. HDP is the
>> perfect "provenance receipt" that can travel alongside an NTI enforcement
>> header. NTI provides the cryptographic bouncer at the door; HDP provides
>> the immutable ledger of who came in.
>>
>> @Kaliya, I would love to frame the NTI paper for the AIW Book of
>> Proceedings around this synthesis: How do we bridge post-incident
>> provenance (like HDP) with execution-time enforcement (like NTI)?
>>
>> Best,
>> Abisheak
>>
>> On Tue, 27 Oct, 2026, 7:30 pm Alan Karp, <alanhkarp@gmail.com> wrote:
>>
>> There are other projects in this space, too.  One of them is
>> https://datatracker.ietf.org/doc/draft-helixar-hdp-agentic-delegation/.
>>
>> --------------
>> Alan Karp
>>
>>
>> On Tue, Oct 27, 2026 at 5:13 AM Abisheak P <abisheakp197@gmail.com>
>> wrote:
>>
>> Hi Xinghua,
>>
>> I completely agree with your Topic 2 regarding revocable, auditable
>> authority for agent chains. I'm the founder of NTI (Neutral Trust
>> Infrastructure), a W3C participant.
>>
>> We actually have a working implementation for this. We use Merkle-chained
>> proofs and Dilithium5 signatures to cryptographically bind execution-time
>> consent to tool calls, preventing agents from exceeding their mandate.
>>
>> If someone is attending AIW in person and raises this, please point them
>> to our live leaderboard (https://nti-leaderboard.vercel.app). I would
>> love to collaborate with you on pushing this as the standard.
>>
>> Best,
>> Abisheak
>>
>> On Tue, 27 Oct, 2026, 12:23 pm Steven Zhao, <zhaoxinghua07@126.com>
>> wrote:
>>
>> Hi all,
>>
>> I'm Xinghua Zhao, an independent researcher working on lifecycle
>> governance of delegated agents — provenance, scope boundaries and
>> revocation (ORCID 0009-0001-0512-1237). I've been following this CG's work
>> on agent discovery, identification and collaboration protocols.
>>
>> Next week (November 6), Agentic Internet Workshop #3 takes place at the
>> Computer History Museum in Mountain View — the open-space event in the IIW
>> tradition, where people building MCP / A2A / UCP / AP2 and the adjacent W3C
>> / IETF / OIDF / DIF work meet in person. I can't attend (I'm based in
>> Beijing), so I'd like to propose two topics through this list, and to ask a
>> favor: if anyone on this list is attending in person, would you be willing
>> to raise them in the opening circle?
>>
>> **Topic 1 — Identity and delegation chains across MCP and A2A: aligning
>> W3C, IETF and OIDF work.**
>> The AIW topics page identifies delegation and authorization as its
>> largest cluster: how authority passes from humans or organizations to
>> agents and stays bounded, revocable and auditable. My interest is where the
>> "each hop individually compliant, but the whole chain exceeding its
>> mandate" problem actually sits in the stack, and how the tracks converge or
>> diverge: this CG and the Agent Identity Registry / Memory Interop groups on
>> the W3C side; CATALIST, the OAuth-on-behalf-of-user and GNAP-based
>> delegation drafts, DAWN and webbotauth on the IETF side; and AIIM on the
>> OIDF side. A shared vocabulary for delegation chains that cross MCP and A2A
>> — and for what a revocation boundary looks like at each hop — would be the
>> outcome I'd hope for.
>>
>> **Topic 2 — Revocable, auditable authority for agent chains:
>> machine-speed, execution-time consent.**
>> Long-running agent chains accumulate authority far beyond the moment of
>> consent. The questions I'd bring: where do execution-time consent
>> checkpoints belong (MCP tool calls, A2A handoffs); what audit logs and
>> telemetry must capture to make delegation auditable across protocol
>> boundaries; and how a human — or a policy layer — retains the ability to
>> pause, halt and revoke a running agent, including when intent drifts from
>> the original mandate.
>>
>> I'd be glad to have notes from these sessions folded into the public Book
>> of Proceedings, and to follow up with authors whose work touches agent
>> identity and authorization afterward.
>>
>> If you're attending AIW #3 and happy to raise either topic on my behalf,
>> please reply here or off-list — much appreciated.
>>
>> Best regards,
>> Xinghua Zhao
>> Independent researcher (SynomosAI initiative)
>> ORCID: 0009-0001-0512-1237
>>
>> [Disclosure: drafting of this message was assisted by AI; all positions
>> reviewed and approved by me.]
>>
>>
>>
>>