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