Author: Abundant Joel Published: June 2026 Version: 1.0 — Protocol Specification Draft

Abstract

In November 2025, researchers at Palo Alto Networks' Unit 42 documented a class of attack called Agent Session Smuggling, in which a malicious sub-agent embeds an unauthorized financial instruction inside a routine response and a parent agent executes it without any visible prompt or human oversight, because the parent agent had no structural way to know what the sub-agent was permitted to do and so it trusted the output, making that trust the vulnerability. NAIAD, the Agent Credential Protocol (ACP), is a two-object Move protocol deployed on Sui that gives every autonomous agent a verifiable onchain identity and a permission-bearing credential whose scope is enforced by Move's type system, making unauthorized actions structurally impossible at the language layer rather than subject to application logic that can be misconfigured, bypassed, or exploited.

1. The Delegation Problem

By the time Sui Overflow 2026 opened its Agentic Web track, the problem it was implicitly asking builders to address had already materialized in production systems, with the Cloud Security Alliance publishing findings showing that 97% of non-human machine identities in enterprise environments carried excessive privileges, credentials scoped far beyond what any single task required, inherited wholesale from parent processes and never narrowed. In multi-agent systems, where a primary agent breaks a complex task into subtasks and hands them to specialist sub-agents, each delegation hop multiplied access rather than constraining it, which meant that by the third hop in a typical orchestration chain, a sub-agent might carry authority the original human user never consciously granted.

The cost of this is documented in two specific incidents. Agent Session Smuggling (November 2025), researched by Palo Alto Networks' Unit 42, demonstrated silent stock execution buried in a routine response. A financial assistant agent requested market insights from a research agent, the research agent returned a clean summary with a hidden stock trade command embedded inside it, and the trade executed before any alert fired. Cross-Agent Privilege Escalation (September 2025), demonstrated by security researcher Johann Rehberger, showed one agent rewriting another agent's configuration file mid-task in development environments where multiple AI agents share a codebase, triggering a self-reinforcing loop where each compromised agent reinfected the others with no mechanism for the human principal to intercept it. Both vulnerabilities shared the same root cause: the system had no standard for encoding what an agent was authorized to do, and authorization defaulted to whatever the agent could technically access.

On Sui specifically, where the infrastructure for autonomous agents is maturing rapidly with parallel transaction execution, zkLogin for human-free onboarding, and sponsored transactions that remove gas as a friction point, this gap becomes the most consequential unsolved problem in the ecosystem. Sui's own developer blog in February 2026 described what agents on Sui would need: programmable guardrails, spending limits, and verifiable policy enforcement, yet the infrastructure to deliver it had not yet been built.

2. The Prior Art and What It Leaves Open

The broader agent identity space has been active. The W3C AI Agent Identity Community Group has been drafting standards around Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs) since 2024, with the goal of giving agents cryptographically signed identity documents that travel with them across service boundaries. The IETF's Agent Credential Attestation Protocol (ACAP) proposes JWT-based token exchange for agent pipelines. Visa's Trusted Agent Protocol handles merchant-facing agent authentication during payment flows. Each of these addresses a genuine dimension of the problem, proving an agent is who it claims to be and that it carries authorization for the action it is attempting.

What connects all of them is where enforcement actually lives. A DID is a document, a VC is a signed token, and a JWT is a string of bytes whose validity is checked by application code written by developers, running on servers, subject to bugs, misconfigurations, and deliberate circumvention. The agent presents a credential, the service reads it, and the service decides whether to allow the action through logic that is mutable and separated from the protocol itself.

On Ethereum, MetaMask's Delegation Toolkit brought account abstraction-based scoped permissions to the EVM, allowing developers to define policy-bound smart accounts with limited delegation chains built on ERC-4337 and ERC-7710, and by April 2026 this extended to full Advanced Permissions where a user can authorize an agent to spend up to a defined amount of a specific asset within a defined time window. Coinbase's AgentKit extended the agent action space with MPC-secured key management and an Agentic Wallets infrastructure that reached general availability in February 2026 with per-transaction limits and session caps built in. Both operate within the account model that the EVM inherits, where permissions are properties of accounts encoded in contract state and validated by contract logic, meaning a permission exists as a record that can be read, written, and reasoned about in code that runs at execution time.

On Sui, Turnkey's infrastructure brings a policy engine that enforces signing rules according to configurable constraints for agents operating on Sui, production-ready and already being used by teams building agent-facing DeFi products, but the policy engine lives off-chain in Turnkey's infrastructure rather than in the blockchain itself, meaning the enforcement boundary is a service that wraps Sui rather than the chain's own execution layer. As more agent frameworks build natively on Sui's object model, the off-chain policy gap will widen with them.

NAIAD addresses this by moving enforcement one layer deeper, into the type system of the language that all Sui smart contracts are written in.

3. What Move's Type System Makes Possible

Move was designed with a specific constraint that most programming languages do not share: resources cannot be copied or silently discarded. A value that represents something of real consequence, whether a token, an authorization, or a credential, must be explicitly transferred or consumed, and the compiler refuses to compile code that copies a non-copyable resource or drops a resource without handling it. These are compile-time guarantees rather than runtime checks, which means no amount of clever input or unexpected call sequence can cause them to fail.

The ability system that implements this in Move is declarative. Every struct in Move declares which abilities it possesses, copy, drop, store, key, and the compiler enforces those declarations across every function that touches the type. A struct without copy cannot be duplicated anywhere in the codebase by any caller, regardless of how the function is invoked, and a struct without drop cannot be silently discarded because every execution path must account for it.

This property, applied to a permission object, produces something qualitatively different from a permission record in a database or a claim in a JWT. A permission object without copy exists in exactly one location at any given time, belongs to one agent, and transferring it to another agent removes it from the first. A permission object whose functions require it as a parameter cannot be invoked by any caller who does not hold it, and Move's ownership model ensures that holding it means actually possessing the object on the blockchain, possessing a reference to something real rather than a shared record that can be modified or revoked at the data layer. The permission and its enforcement are the same object, written in the same language, deployed in the same transaction.

4. The Protocol

NAIAD is two objects and the functions that operate on them, deployed as a Move package on Sui under the Agent Credential Protocol (ACP) standard.

The name draws from Greek mythology and natural science simultaneously. A Naiad is a water nymph bound to her specific body of water — not water in general, her assigned water. She cannot leave it, cannot be transferred to another body, and ceases to exist when that water is destroyed. She has no existence outside what she was issued to. In natural science, a naiad is the aquatic larval stage of certain insects — a form that exists only within a defined aquatic environment, unable to persist outside it. In astronomy, Naiad is the innermost moon of Neptune, locked in an orbital path it cannot exit. Every meaning across mythology, science, and astronomy arrives at the same property: bound to one place, one purpose, one scope of existence. That is the PermissionCapsule exactly — bound to the agent it was issued for, unable to be duplicated, destroyed on revocation, leaving the agent without authorization the moment the Naiad's water is gone.

AgentIdentity is a top-level Sui object, owned by the address of the agent it represents, carrying a unique onchain identifier, the address of the human principal who spawned the agent, a human-readable name, a creation timestamp in Sui epochs, and a dynamic field that accumulates the agent's action history as onchain events. The dynamic field approach means the identity object does not need to pre-define the full structure of the history it will accumulate, and new record types can be attached as the protocol extends to cover new action categories without requiring a migration of existing identity objects.

PermissionCapsule (the Holdfast) is the authorization layer, declared without the copy ability so it exists in exactly one location at any time and cannot be duplicated by any Move code anywhere regardless of how a caller frames the transaction. The capsule carries a reference to the AgentIdentity it was issued for, the set of permitted action types from the ACP permission vocabulary, the specific protocol addresses the agent may interact with, a per-transaction spend ceiling, a daily spend ceiling, a lifetime spend ceiling, a running total of value moved against those ceilings, and a Sui epoch at which the capsule expires and Move begins rejecting it automatically. Every function in the protocol that executes a consequential action requires a &mut PermissionCapsule as a parameter, where the mutable reference ensures spend tracking updates propagate and the type requirement ensures the function cannot be invoked without a valid capsule in the caller's possession.

Revoking an agent's authority is a destructive operation on the capsule object: the object is consumed and permanently deleted from the blockchain state using object::delete. The agent's capability ceases to exist as an object, and every function that requires it becomes unreachable by that agent from that point forward with no further action required from the principal.

The Permission Vocabulary defines the atomic action categories that a capsule can authorize. Version 1 of NAIAD covers eight types: QUERY for reading public onchain state; SWAP for token exchange on DEXs; SUPPLY for depositing assets into lending protocols like NAVI or Scallop; COLLECT for claiming earned yield and rewards without moving principal; STAKE for native SUI staking operations; TRANSFER_WHITELIST for sending assets to a pre-approved set of addresses locked into the capsule at issuance; ORDER for placing and cancelling limit orders on DeepBook; and DELEGATE for the creation of sub-agent capsules.

The DELEGATE permission carries the most consequential constraint in the protocol: any capsule issued to a sub-agent must be a strict subset of the parent capsule's permissions, checked at issuance time by the Move function that creates sub-agent capsules so that the function reverts if any permission in the requested sub-capsule falls outside the parent's authorized set. Cross-Agent Privilege Escalation becomes architecturally impossible within NAIAD rather than a risk to be mitigated by careful development practice.

5. Integration Architecture

Protocols already deployed on Sui, lending platforms, DEXs, order books, carry existing contract interfaces designed for human-initiated transactions, and requiring them to rewrite those interfaces to accept PermissionCapsule parameters would ask teams to audit, redeploy, and re-integrate production contracts, a high adoption barrier for infrastructure that has no track record yet.

NAIAD solves this with a thin adapter layer, where an ACP adapter is a Move module that accepts an agent's PermissionCapsule and the parameters of the intended action, validates the capsule against NAIAD's enforcement functions checking action type, protocol whitelist, spend ceilings, and expiry, and on successful validation calls the target protocol's existing interface in the same transaction using Sui's Programmable Transaction Blocks. The target protocol sees a standard transaction while the agent's authorization has already been enforced before that transaction is constructed, and because the validation and execution are atomic through PTBs, if the capsule check reverts the protocol call never executes and if the protocol call fails the spend counter update does not persist.

NAIAD adoption for protocol teams is a one-time module deployment referencing the ACP package ID on Sui rather than a contract migration, and once a protocol's adapter exists, every agent framework that uses NAIAD can interact with that protocol through a single auditable interface. The package ID, the onchain address of the deployed protocol, functions as the coordination point, giving protocol teams the kind of dependency stability that makes integration worthwhile because the behavior of a specific package ID does not change without a versioned upgrade.

6. What This Enables

The six months that follow the first real protocol integration of NAIAD will determine whether it becomes ecosystem infrastructure or a well-documented experiment, because the integration network is the asset. Each protocol that builds an adapter referencing the ACP package ID makes the protocol more useful to every agent framework that uses NAIAD, and each agent framework that adopts NAIAD makes every integrated protocol more accessible to agent builders. This is the same flywheel that made HTTP useful: the value of the shared standard grew with each new participant, and the cost of opting out grew alongside it.

The path that opens from here is the foundation for multi-agent coordination on Sui that human principals can actually trust, where the scope of every agent's authority is written into the blockchain state at the moment of delegation, the audit trail of every action the agent took is queryable onchain from the identity object's event history, and revoking an agent's authority is a single transaction rather than a revocation process dependent on a centralized service responding in time. The problem that Agent Session Smuggling exposed in November 2025 was a missing layer of infrastructure, and NAIAD is a proposal for what that layer should look like on the chain most positioned to host the Agentic Web.

Limitations

NAIAD v1 covers Sui-native agent operations. Cross-chain operations, where an agent spawned on Sui interacts with protocols on other networks, are outside the current scope. The subset inheritance rule for DELEGATE permissions is enforced at issuance time by the Move function that creates sub-capsules, meaning protocol teams integrating NAIAD should audit their adapter implementations against the canonical ACP package rather than self-implementing the issuance logic, as a compromised adapter could theoretically bypass this check. Version 1 covers eight action types sufficient for demonstrating the protocol's enforcement properties, with borrowing, liquidity provision, governance voting, NFT market actions, onchain content publishing, and gaming asset management planned for v2.

Conclusion

NAIAD gives the authorization question a precise answer where before there was only a gap. The two objects in this protocol, an identity and a naiad, give builders the smallest possible surface area for solving agent authorization correctly, with Move's type system guaranteeing that correctly means something structural rather than something aspirational. The next task is integration: the architecture shows what the protocol enables, but only real adapter implementations built against it will show how widely the Sui ecosystem is ready to build on a shared authorization standard.

NAIAD, the Agent Credential Protocol, is released as open infrastructure under the MIT License. Protocol integrations, adapter implementations, and community feedback are welcome at the project repository.

Abundant Joel · June 2026