Skip to main content
Grant authority to an agent. Identity alone (agent-identity) does not allow the agent to act. The authority record shows who approved the agent, what it may do, how much it may spend, and when access expires. Check ID: agent-delegation controllerWallet is the approving account — the address that signs this step. See Agent concepts.

Setup

1

Check

neus_contextneus_agent_link
2

Create

neus_agent_create. Leave out controllerWallet when the signed-in profile account should approve.
3

Confirm

neus_agent_link until linked: true
Or finish on NEUS via hosted verify.

SDK

Both accounts need a CAIP-2 network reference (controllerChainRef, agentChainRef) unless the request already includes chain or chainId. One-time user approval lets your backend create receipts without asking for a signature on every request. This is different from creating a portal in your profile for hosted checks. See Integrations.
  1. User signs in on NEUS
  2. User approves the permissions once
  3. Your app stores the receipt ID in qHash
  4. Your backend calls verification with x-neus-app — no per-request signature
Permissions:
  • app:<appId> — matches your x-neus-app header
  • origin:<url> — restrict to your domain
  • origin:* — any origin
Send x-neus-app: your-app-id and matching site origin on verification requests. On Node, set appOrigin: 'https://yourapp.com' on NeusClient (or pass Origin via extraHeaders).

Payment limits

maxSpend is a whole-number string in token base units. For USDC (6 decimals), 25 USDC = "25000000". Use toAgentDelegationMaxSpend('25', 6) from @neus/sdk. When scope: "payments:x402" and allowedPaymentTypes: ["x402"] are set, the agent can settle metered API calls via x402 without a NEUS account. The calling application enforces the maxSpend cap client-side before signing each payment — the protocol does not decrement maxSpend server-side. When the cap is exhausted, the application stops signing payments and the agent is refused. See x402 pay-per-call for the full settlement flow.

Fields

The protocol accepts bounded action strings in allowedActions and deniedActions. deniedActions always wins over allowedActions.

Human approval pattern

Your application enforces the limits recorded in the permission receipt:
At runtime:
  1. Check the current permission receipt before the tool call.
  2. Apply deniedActions first.
  3. Pause when the policy requires human approval.
  4. Continue only after approval is confirmed.
Schema: agent-delegation.json.

Result

A receipt ID returned in qHash. Check it with neus_agent_link or neus_proofs_check before an action.

Revoke

Set expiresAt and maxSpend when money or high-risk actions are in scope.
Last modified on July 24, 2026