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

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