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

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, < mailto: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" < mailto: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 < mailto: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, < mailto: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 < mailto: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, < mailto: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 < mailto: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, < mailto: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 < mailto: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, < mailto: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.]