Grantex

Grantex

AI Agent Authorization and Delegated Access, with Open-Source SDKs

What OAuth 2.0 is to humans, Grantex is to agents.

Docs | Quickstart | Release JSON | LLM Index | Spec | IETF Draft

Ownership: Grantex is owned by Orchestrum Technologies LLP. Inventor and owner: Sanjeev Kumar. Contact: sanjeev@orchestrum.in or mishra.sanjeev@gmail.com.

Website operators: marketing enquiry delivery and acceptance.

For a scoped technical pilot, begin with security controls, token verification, and OACP authority boundaries. AgenticOrg runs buyer/seller agents and workflows; Grantex governs delegated authority; merchant systems and payment providers retain operational authority. Discuss a bank, fintech or merchant integration at sanjeev@orchestrum.in, without sharing credentials or private customer records.

Licence

Grantex has two licences. LICENSING.md lists which directory uses which.

• Platform, free: an individual using, copying or changing it for their own personal purposes (learning, personal study, experiments and hobby projects), not acting for, on behalf of or for the benefit of any organisation.
• Platform, needs prior written permission from Orchestrum Technologies LLP: any use by or for an organisation, whether companies, firms, sole proprietors' businesses, charities, schools, universities, research bodies or government, and whether paid or free. That includes evaluation, testing, pilots, internal use, hosting or SaaS, resale, distribution and embedding the platform in another product. Commercial use of the hosted services (the grantex.dev APIs) also needs an agreement, even through the open SDKs. See COMMERCIAL-LICENSE.md and write to sanjeev@orchestrum.in.
• Existing users: releases published before 21 October 2026 remain available under the terms they were released with. Versions and updates of the platform published from that date are not, so an organisation needs written permission to use them.
• Names: "Grantex" and "AgenticOrg" are trademarks of Orchestrum Technologies LLP. Commercial use of the names, logos or brand needs Orchestrum's prior written approval, including with the Apache-licensed SDKs and earlier versions. See TRADEMARKS.md.

What is Grantex?

Grantex is a delegated authorization protocol and reference implementation for AI agents, with open-source SDKs and a source-available server. It gives each agent a verifiable identity and scoped, time-limited, revocable authority from a human or organization, with multi-agent delegation, service-side verification, and audit records.

Grantex complements OAuth 2.0 and MCP: OAuth handles application and user authorization, MCP connects models to tools, and Grantex proves which agent may perform which action for which principal. Use Grantex when an AI agent acts for a person or organization and a relying service must verify exactly what that agent may do.

For AgenticOrg business onboarding cases, Grantex grants provide delegated tool authority while AgenticOrg owns tenant isolation, case state, the local case-purpose allowlist, human review and the provider call boundary. The last verified AgenticOrg integration does not enforce token-level case purpose or per-case caps. Published Python grantex==0.7.2 contains purpose and cap APIs, but that integration has not been verified to use them. See the governed-case integration boundary and release status. Neither this repository nor an MCP tool grants an agent authority to approve a case as a human.

Agent Prepaid Wallets and x402 v2

Repository source includes principal-controlled prepaid wallets for AI agents. A principal can assign one or multiple wallets, apply assignment, wallet, agent, shared budget-group, principal, and developer controls, constrain recipients, resource origins, actions, merchants, purposes, projects, and cost centers, require an exact human approval, govern reload velocity, and block one assignment, one wallet, or all wallets available to an agent. Authorizations reserve value atomically in PostgreSQL and are bound to the agent's DPoP OAuth identity and the policy-evaluated semantic context.

@grantex/x402 uses official x402 v2 PAYMENT-REQUIRED, PAYMENT-SIGNATURE, and PAYMENT-RESPONSE messages. The old simulated X-Payment-Proof path is not used. sandbox_ledger is implemented end to end; external custody records deliberately fail closed unless a configured provider can verify funding and settlement. The source checkout now includes opt-in Base native USDC EIP-3009 payments with policy-gated signing, verified funding, durable signature retries and finalized-chain reconciliation. Python 0.7.2 and Go v0.4.3 publish the EVM response and reconciliation APIs; neither adds an automatic HTTP payment wrapper. Published TypeScript 0.8.2 and x402 0.4.1 include the opt-in automatic Base 402/sign/retry flow. All four releases are registry verified. See the Base USDC custody guide, including the limit that blocking cannot recall an already issued on-chain signature.

import { PrepaidWalletAgentClient } from '@grantex/sdk';

import { createX402Agent } from '@grantex/x402';

const walletAgent = new PrepaidWalletAgentClient({ oauthClient, accessToken }); const x402 = createX402Agent({ authorizePayment: walletAgent.x402Authorizer, // walletId is optional; omit it for policy-based wallet selection. });

const logicalPaymentId = 'order_01JZ8Y6Q2M4N7P9T'; const response = await x402.fetch('https://merchant.example/paid-resource', { // The merchant uses this header to recover a response lost after settlement. headers: { 'Idempotency-Key': logicalPaymentId }, // Grantex uses this option to recover a reservation response lost before settlement. idempotencyKey: logicalPaymentId, });

For side-effecting resources, the merchant must durably cache the business result under Idempotency-Key. Grantex settlement is idempotent, but a settled payment authorization cannot be verified or execute protected work a second time.

The OAuth grant must include wallet:spend and the exact merchant action scope advertised as extra.grantexScope; wallet assignment policy can restrict that human-approved authority but cannot add to it.

Where Grantex fits

Grantex owns delegated agent identity, semantic spend policy, cross-wallet budgets, exact approvals, atomic reservations, stop controls, and audit. An AgenticOrg deployment or another agent runtime owns orchestration and the human interaction. The wallet issuer or custodian remains responsible for KYC/KYB, AML and sanctions controls, custody, network authorization, MCC/geography/card controls, settlement, FX, refunds, disputes, fraud, and reconciliation. The merchant remains responsible for server-trusted price/payee data, order idempotency, settlement gating, and delivery of the paid result.

See Agent Wallet Governance for the complete responsibility matrix, policy composition, exact approval protocol, and honest residual gap list.

The managed clients are implemented in registry-verified @grantex/sdk@0.8.2, @grantex/x402@0.4.1, Python grantex==0.7.2, and Go v0.4.3. External custody, principal notification delivery, and merchant result idempotency remain operator responsibilities. See the x402 integration guide, wallet lifecycle, and production-readiness guide.

Self-hosted prepaid-wallet dependencies

Running the auth-service does not provision every dependency needed for a real-money product. Self-hosting operators must explicitly provide and test:

• PostgreSQL migrations 091_agent_prepaid_wallets.sql and 092_layered_wallet_spend_controls.sql, backups, restore, and reconciliation for the append-only wallet ledger and policy decisions;
• HTTPS ingress for the exact OAuth audience, including /v1/prepaid-wallets and /v1/prepaid-wallets/** (a static-host 404 breaks agent wallet access even while the origin service is healthy);
• a provider-specific custody, funding, settlement, webhook-deduplication, and recovery adapter before using external wallets; without one, Grantex deliberately returns 503 CUSTODY_ADAPTER_UNAVAILABLE;
• an SSE/WebSocket notification bridge for reload events when a principal must be notified by email, SMS, Slack, WhatsApp, or another external ch