ArcenAuth — Agent Authorization & Mandates

Autonomous multi-agent systems require delegated financial capabilities. Traditional API keys and private keys provide binary permissions: an agent has total wallet access or none. ArcenAuth solves this with a 3-layer cryptographic authorization stack:

Layer 3: Autonomous Agent Mandates (AAM) — Cryptographically signed delegation credentials (ArcenPayAgentMandate) constraining spend limits, token whitelists, recipients, domains, and expiry dates.
Layer 2: Deterministic Policy Engine (ArcenPolicy) — deterministic evaluation rules evaluated prior to signing any transaction.
Tier 1 Invariant: On-Chain Revocation (SessionVault) — Authoritative on-chain registry guaranteeing instant revocation enforcement.

┌─────────────────────────────────────────────────────────────────────────────┐
│                       ARCENAUTH LAYER ARCHITECTURE                          │
│                                                                             │
│  Layer 3: Autonomous Agent Mandate (AAM)                                    │
│    ├─ Issuer: Root Agent / Human Wallet                                     │
│    ├─ Subject: Worker Agent Address                                         │
│    ├─ Scope: maxPerTxn, maxDaily, maxTotal, allowedChains, allowedDomains   │
│    ├─ Delegation Chain: parentScope ⊇ childScope (monotonic narrowing)      │
│    └─ Signed via: EIP-712 (EVM) or Ed25519 (Stellar, Solana)               │
│                                                                             │
│  Layer 2: Deterministic Policy Engine (ArcenPolicy)                         │
│    ├─ Precedence: Root Co-sign ──> Explicit DENY ──> Explicit ALLOW ──>     │
│    │              Default DENY                                              │
│    └─ Rules: tx.amount <= 10.0, resource.domain IN whitelist, velocity      │
│                                                                             │
│  Tier 1 Invariant: On-Chain Revocation (SessionVault contract)              │
│    ├─ Immutable revocation registry checked at settlement                   │
│    └─ Revoked mandates can never settle on-chain                            │
└─────────────────────────────────────────────────────────────────────────────┘

Autonomous Agent Mandates (AAM)

An ArcenPayAgentMandate is an off-chain cryptographic voucher signed by a root wallet or parent agent:

import { ArcenAgent } from "@arcenpay/agent";

const rootAgent = new ArcenAgent({
  privateKey: process.env.ROOT_AGENT_KEY!,
  chainId: 9100000, // Solana Mainnet (or 677 BOT Chain, 9000001 Stellar)
});

// Issue a bounded mandate to a worker agent
const mandate = await rootAgent.issueMandate({
  childAgentId: "worker-market-researcher",
  childPublicKey: "0xWorkerPublicKey...",
  childScope: {
    maxPerTxn: "0.50",
    maxDaily: "5.00",
    maxTotal: "50.00",
    allowedTokens: ["USDC", "USDT"],
    allowedRecipients: ["*"],
    allowedResourceDomains: ["api.coingecko.com", "data.arcenpay.com"],
    validFrom: new Date().toISOString(),
    validUntil: new Date(Date.now() + 7 * 86400000).toISOString(), // 7 days
    requiresCoSignAbove: "5.00",
  },
});

Delegation Chains & Monotonic Scope Narrowing

Sub-agents can delegate further sub-mandates. To prevent privilege escalation, ArcenAuth mathematically enforces monotonic scope narrowing (isScopeSubset):

Child maxPerTxn $\le$ Parent maxPerTxn
Child maxDaily $\le$ Parent maxDaily
Child maxTotal $\le$ Parent maxTotal
Child allowedTokens $\subseteq$ Parent allowedTokens
Child allowedRecipients $\subseteq$ Parent allowedRecipients
Child allowedResourceDomains $\subseteq$ Parent allowedResourceDomains
Child validity interval $[validFrom, validUntil] \subseteq$ Parent interval

// Worker delegates to a micro-worker sub-agent
const subMandate = await workerAgent.issueSubMandate({
  childAgentId: "micro-worker-scraper",
  childPublicKey: "0xMicroWorkerKey...",
  childScope: {
    maxPerTxn: "0.05",
    maxDaily: "0.50",
  },
});

Deterministic Policy Engine (`ArcenPolicy`)

Before signing any voucher or link payment, the agent runtime evaluates policies with deterministic precedence:

Root Co-Sign: If transaction has valid root co-signature, allow immediately.
Explicit Deny: If ANY matching policy rule evaluates to EFFECT_DENY, the transaction is blocked immediately.
Explicit Allow: If at least ONE matching policy rule evaluates to EFFECT_ALLOW and no deny matches, the transaction is permitted.
Default Deny: If no policy matches, the transaction is rejected.

agent.addPolicy({
  policyId: "limit-market-intel",
  name: "Market Intel Spend Rule",
  effect: "EFFECT_ALLOW",
  condition: "tx.amount <= 0.05 && (resource.domain == 'api.coingecko.com' || resource.domain == 'api.cryptonews.com')",
  priority: 100,
});

x401 Agent Identity, Provenance & Attestation

While x402 defines autonomous payment execution (HTTP 402 Payment Required), x401 represents the standard for agent identity, provenance, and credential authentication (HTTP 401 Unauthorized).

Feature	x402 (Payment Settlement)	x401 (Identity & Provenance)
Core Function	Value transfer, micropayment voucher, auto-replay	Agent KYC/KYA, attested identity, credential check
Trigger	HTTP `402 Payment Required`	HTTP `401 Unauthorized` / policy threshold
Execution Cost	Negligible (off-chain voucher with batched ZK settlement)	Depends on identity issuer (W3C DID, OIDC, EAS, WorldID)
Arcen Role	Core Standard (Always enabled)	Optional Security Gate (Gated for enterprise/high-value spend)

Why x401 is an Optional Capability Gate

Sub-Cent Micropayments: Agents spending $\$ 0.001$ per API request must not encounter heavy identity verification handshakes.
High-Value Actions ( $>\$ 10$ or sensitive API domains): a mandate can carry an x401 humanAttestation record. When present and required, settlement expects a verified credential (or root co-sign) before releasing funds:

mandate.humanAttestation = {
  required: true,
  protocol: "x401",
  issuer: "https://identity.arcenpay.com",
  credentialRef: "cred_abc123",
  presentedAt: new Date().toISOString(),
  verifierPolicy: "spend>10.00",
};

Revocation

Mandates declare a revocation method: onchain_registry (an authoritative registry in the SessionVault contract) or offchain_endpoint (the mandate’s checkUrl, the default). agent.revokeMandate() broadcasts to the configured registry and, when on-chain revocation is configured, records the revocation on-chain. Settlement refuses any mandate marked revoked, so a revoked delegation cannot move funds even if off-chain policy or API state is stale. Query authoritative status with GET /api/v1/mandates/:id/status or agent.getMandateStatus().

Get started

Core concepts

Guides

Integrations

ArcenAuth — Agent Authorization & Mandates

Autonomous Agent Mandates (AAM)

Delegation Chains & Monotonic Scope Narrowing

Deterministic Policy Engine (`ArcenPolicy`)

x401 Agent Identity, Provenance & Attestation

Why x401 is an Optional Capability Gate

Revocation

​Autonomous Agent Mandates (AAM)

​Delegation Chains & Monotonic Scope Narrowing

​Deterministic Policy Engine (ArcenPolicy)

​x401 Agent Identity, Provenance & Attestation

​Why x401 is an Optional Capability Gate

​Revocation

Autonomous Agent Mandates (AAM)

Delegation Chains & Monotonic Scope Narrowing

Deterministic Policy Engine (`ArcenPolicy`)

x401 Agent Identity, Provenance & Attestation

Why x401 is an Optional Capability Gate

Revocation