Grantex

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 [email protected].
• 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/[email protected], @grantex/[email protected], 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 channel; no built-in wallet-email delivery is claimed;
• a merchant-side durable result cache keyed by the HTTP Idempotency-Key for side effects after settlement;
• independent security, provider, reconciliation, incident-response, and applicable legal/regulatory review.

The server deployment and each SDK release are separate. Registry consumers should verify an exact version before installing it rather than inferring availability from repository manifests. The production-readiness guide contains the full hosting checklist and a maintainer-only PowerShell publication runbook.

Supply-chain and license controls

The security workflow audits every tracked npm lockfile, every tracked Python project and requirements surface, and all three Go modules. Dependabot coverage is checked against the repository manifests, external GitHub Actions and container images are pinned to immutable digests, and unreviewed npm license identifiers fail CI. Run npm run audit:supply-chain and npm run audit:python locally before a release.

The Grantex licences cover Grantex source, not third-party dependencies. See THIRD_PARTY_NOTICES.md for the current Sharp/libvips LGPL and caniuse-lite CC-BY distribution notes, and the supply-chain security guide for the operator checklist. This inventory is an engineering control, not a legal non-infringement opinion; distributors must review the exact artifacts they ship.

OAuth Agent Grants Profile

The hosted auth service and repository TypeScript client implement the three roles in candidate draft-mishra-oauth-agent-grants-03. The tested profile requires PAR, PKCE S256, DPoP sender constraints, RFC 9207 response issuer validation, five-minute access tokens, rotating refresh tokens with family replay revocation, 300-second exact-request recovery when a refresh response is lost, AES-256-GCM encrypted recovery state with expiry cleanup, same-resource RFC 8693 attenuation, and RFC 7009 revocation.

Verification completed with 2,138 auth-service tests, 456 TypeScript SDK tests, and 255 tests across 23 sequential Docker E2E files. This is self-assessed evidence for the tested Grantex configuration, not independent interoperability certification, OAuth Working Group adoption, or IETF endorsement. The updated OAuthAgentClient is published in registry-verified @grantex/[email protected].

Revision -02 remains the current Datatracker publication. Candidate -03 must not be uploaded before 2026-09-09 and requires a fresh explicit approval after the scheduled final review.

Open Agentic Commerce Protocol (OACP) Authority

Open Agentic Commerce Protocol (OACP) is Grantex's agentic-commerce trust and artifact-authority layer. Grantex governs OACP policy, signed artifact and mandate issuance or refusal, verification, and compatibility adapters. AgenticOrg owns buyer and seller AI-agent runtime, merchant self-service onboarding, Shopify connector runtime, future merchant connector setup intent, buyer sessions, channel bridges, OACP cache, and provider-owned capability verification.

Merchant systems such as Shopify, future WooCommerce/ERP sources, POS systems, and provider systems remain the source of record. Provider, bank, POS, and payment rails own mandate, payment, and in-store execution. Grantex signs and verifies artifacts; it is not a merchant connector runtime or a toll booth for every buyer and seller message.

flowchart LR  merchant[Shopify, future ERP/WooCommerce, POS, provider systems] --> agentic[AgenticOrg buyer and seller runtime]  agentic -->|redacted authority request| grantex[Grantex OACP authority]  grantex -->|ES256-signed OACP artifacts or blockers| agentic  agentic --> buyer[Buyer surfaces]  agentic -->|capability check or handoff| provider[Pine Labs Plural/P3P, bank/POS/provider rails]

Start with the OACP runtime launch closure PRD, OACP authority overview, merchant self-service config boundary, truth inventory, AgenticOrg integration guide, POS bridge boundary, and operator runbook. The older Commerce V1 overview remains historical/contextual and should not be used to imply that Grantex owns AgenticOrg merchant connector runtime.

Agent Trust Registry: accredited issuers and Agent Passports

The registry lets a relying party, such as a merchant, a payment service provider or an API, check an AI agent before it acts. It answers three questions: which software the agent is, which key it holds, and which accredited issuer vouches for it. The answer comes as a computed trust level, not a claim the agent makes about itself. The grant still says what the agent may do; the passport says who the agent is. See Passport vs grant.

New behaviour on existing paths is off by default. Turn it on per deployment:

• REGISTRY_PUBLIC_ENDPOINTS_ENABLED serves the unauthenticated reads: the issuer list, the status lists, the lookup without an API key and the manifest.
• PASSPORT_BOUND_GRANTS_ENABLED turns on passport-bound grants.
• AGENT_KEY_HISTORY_MIRROR_ENABLED makes POST and PATCH /v1/agents write the agent's key into the key history, and refuse a key that is compromised or belongs to another agent.
• REGISTRY_ATTESTATION_EDDSA_ENABLED accepts EdDSA attestations as well as ES256.

Self-hosting lists every variable. Guides for each audience:

• Becoming an accredited issuer
• Registering agents, for providers
• Verifying agents, for relying parties

The specifications are registry federation, attestations, agent keys, Agent Passport 1.0, passport binding and verification. This Agent Passport, an SD-JWT VC issued by an accredited issuer, is separate from the MPP AgentPassportCredential described below.

Demo: developer opt-in attestation

make demo-attest runs the registration flow end to end against the repository's mock accredited issuer, with no external party: register an agent, prove its key, request attestation through the issuer adapter seam, see the level attested in the public lookup, revoke at the issuer, and see the level drop. make demo-verify goes on to a grant bound to the passport, a relying party's verify() passing, the issuer revoking and verify() denying, and the verifier's adversarial fixtures all denied. Each step is labelled live (the registry), fixture (the mock issuer) or verifier. See Running the Mock Issuer and Verifying Agents.

Current Releases

Grantex components are independently versioned. The protocol specification remains v1.0 Final; SDK, MCP package, and roadmap milestone versions are separate release lines and do not represent a monorepo-wide version.

Public releases below were verified on 2026-10-04. Repository versions are release candidates until the corresponding registry confirms publication.

The current releases are TypeScript 0.8.2, Python 0.7.2, Go v0.4.3, CLI 0.4.2, gateway 0.3.0, and MCP Auth 4.1.0. See the complete migration guide before upgrading: Node.js requirements, audience binding, capped-call amounts and online revocation defaults are breaking changes.

TypeScript 0.8.2 and Python 0.7.2 include service-side enforce() audience binding, denial of capped calls without trusted amounts, and online revocation by default. Register the agent's resource servers before audience-bound authorization, configure the intended audience at the service boundary, and supply a validated amount for every capped call. Offline verification alone does not prove current revocation; integrations must explicitly wire their current-state enforcement. Node.js 22.12+ is required for the changed npm packages. See release limitations.

The October 4 npm and PyPI artifacts match their validated CI archives; the Go tag resolves through the public proxy and its downloaded module passed tests and vet. A clean Python SDK install passed on the workstation. Earlier Docker testing applies to the versions in the historical validation report.

Deployment responsibilities: MCP Auth 4.1.0 supports durable shared storage, rendered consent and corrected code handoff. Configure shared state, resource audience, a required host-authenticated human-principal resolver and trusted current-grant verification before production use. A consent page does not itself authenticate a human or provision passkeys. See the release-status guide.

Repository development status: the auth service enforces Redis-backed Free/Pro/Enterprise developer budgets of 100/500/2,000 requests per minute on API-key routes handled by the standard auth plugin; revoking and the emergency stop have a budget of their own, as do the revocation feed and status reads. Custom-auth quota policy remains open and the managed-service rollout remains independent of SDK publication.

Omit a version pin to install the registry's current latest release. See the release-status documentation, COMPATIBILITY.md for the full package matrix, and CHANGELOG.md for release notes.

• @grantex/gemma: Offline consent bundles and on-device verification examples
• MCP Authorization Server (@grantex/mcp-auth): OAuth 2.1 + PKCE endpoints with durable storage adapters, rendered consent, authenticated human-principal resolution, resource binding and current-grant verification; version 4 requires host authentication configuration
• MCP Tool Server (@grantex/mcp): Agent-facing Grantex tools for MCP clients
• @grantex/dpdp: DPDP Act 2023 and EU AI Act control mappings
• Trust Registry: Public DID verification registry — grantex.dev/registry
• grantex verify: Token inspection CLI — no account needed
• Agent CLI Skills: One-command SKILL.md installation for Hermes, OpenClaw, and portable Agent Skills clients
• Anomaly Detection: Four implemented SQL-backed checks, lifecycle APIs, and stored rule/channel configuration; notification delivery requires a host worker

SDK quickstart

Execution authority and human identity

Signature verification alone does not establish current permission or prove that the executing agent belongs to the authenticated human. Published TypeScript SDK 0.8.1 adds optional per-invocation issuer checks and trusted principal/agent bindings. Python, Go and changed execution integrations are now published. Existing offline defaults are unchanged. Human authentication and live consent remain issuer/host responsibilities. Action-bound decisions and cumulative spend controls must be enforced using the actual execution inputs, not inferred from a valid JWT. See SDK execution authority for setup, package boundaries and release requirements.

npm install @grantex/[email protected]

import { Grantex, verifyGrantToken } from '@grantex/sdk';const gx = new Grantex({ apiKey: process.env.GRANTEX_API_KEY });
// 1. Register an agent, then request authorization from a userconst agent = await gx.agents.register({  name: 'quickstart-agent',  description: 'Grantex quickstart agent',  scopes: ['calendar:read', 'email:send'],});const auth = await gx.authorize({  agentId: agent.id,  userId: 'user-456',  scopes: ['calendar:read', 'email:send'],});
// Live mode requires consent at this URL and returns the code to your callback.// Sandbox or policy auto-approval can return the code immediately.if (!auth.code) {  console.log(`Approve access at: ${auth.consentUrl}`);} else {  // 2. Exchange the authorization code for a scoped, signed JWT  const { grantToken } = await gx.tokens.exchange({ code: auth.code, agentId: agent.id });
  // 3. Verify locally using the issuer's published JWKS  const grant = await verifyGrantToken(grantToken, {    jwksUri: 'https://api.grantex.dev/.well-known/jwks.json',  });  console.log(grant.scopes); // ['calendar:read', 'email:send']}

python -m pip install grantex==0.7.2               # Python SDKgo get github.com/mishrasanjeev/[email protected] # Go SDK (Go 1.26.1+)npm install @grantex/[email protected] @grantex/[email protected] # MCP endpoint authorizationnpm install -g @grantex/[email protected]                   # Optional CLI tooling

Hermes, OpenClaw, and any agent CLI

Shell-capable agents use the same JSON-first CLI; no agent-specific SDK is required:

npm install -g @grantex/[email protected]grantex agent install --target openclaw  # writes ./skillsgrantex agent install --target hermes    # writes ~/.hermes/skills/grantexgrantex agent install --target portable  # writes ./.agents/skills

The bundle installs use-grantex-cli for delegated-authorization operations and integrate-grantex for service-boundary implementation work. For a different host, use grantex agent install --dir /path/to/skills. Prefer --env, --file, or --stdin token inputs and keep final enforcement inside the protected service.

35 packages across TypeScript, Python, and Go. Integrations for Anthropic SDK, LangChain, OpenAI Agents SDK, Google ADK, Strands Agents SDK, CrewAI, Vercel AI, AutoGen, MCP, Express.js, FastAPI, and Terraform. Use the compatibility matrix for versions, the changelog for release notes, and GitHub Actions for current CI status. SDKs are Apache-2.0; the self-hostable server is under the Orchestrum Personal Use License 1.0, and any organisation needs written permission (see Licence). The new relying-party Python verifier remains private source, not a registry release.

The Problem

AI agents are booking travel, sending emails, deploying code, and spending money — on behalf of real humans. But:

• No scoping — agents get the same access as the key owner
• No consent — users never approve what the agent can do
• No per-agent identity — you know the key was used, but not which agent or why
• No revocation granularity — one agent misbehaves, rotate the key, kill everything
• No delegation control — Agent A calls Agent B? Copy-paste credentials
• No spending limits — an agent with a cloud API key can provision unlimited resources

OAuth and IAM provide essential foundations, but many agent deployments still rely on shared credentials that do not identify the individual agent or encode its delegated authority.

How It Works

Quickstart

1. Register your agent

import { Grantex } from '@grantex/sdk';
const grantex = new Grantex({ apiKey: process.env.GRANTEX_API_KEY });
const agent = await grantex.agents.register({  name: 'travel-booker',  description: 'Books flights and hotels on behalf of users',  scopes: ['calendar:read', 'payments:initiate:max_500', 'email:send'],});
console.log(agent.did);// → did:grantex:ag_01HXYZ123abc...

2. Request authorization from a user

const authRequest = await grantex.authorize({  agentId: agent.id,  userId: 'user_abc123',       // your app's user identifier  scopes: ['calendar:read', 'payments:initiate:max_500'],  expiresIn: '24h',  redirectUri: 'https://yourapp.com/auth/callback',});
// Redirect user to authRequest.consentUrl// Grantex handles the consent UI — plain language, mobile-firstconsole.log(authRequest.consentUrl);// → https://consent.grantex.dev/authorize?req=eyJ...

3. Exchange the authorization code for a grant token

// After user approves, your redirectUri receives a `code`.// Exchange it for a signed grant token (RS256 JWT):const token = await grantex.tokens.exchange({  code,                  // from the redirect callback  agentId: agent.id,});
console.log(token.grantToken);  // RS256 JWT — pass this to your agentconsole.log(token.scopes);      // ['calendar:read', 'payments:initiate:max_500']console.log(token.grantId);     // 'grnt_01HXYZ...'console.log(token.refreshToken); // store securely for active-grant rotation

Refresh tokens are single-use and rotate on every accepted refresh. If the refresh HTTP response is lost after the server commits, retry the same previous refresh token immediately; Grantex can recover the already-rotated token pair for five minutes (300 seconds). Refresh does not extend token.expiresAt; after the grant expires, start a new authorization request.

4. Verify the token and use it

// Verify locally after retrieving the issuer's published JWKSimport { verifyGrantToken } from '@grantex/sdk';
const grant = await verifyGrantToken(token.grantToken, {  jwksUri: 'https://api.grantex.dev/.well-known/jwks.json',  requiredScopes: ['calendar:read'],});console.log(grant.principalId); // 'user_abc123'console.log(grant.scopes);     // ['calendar:read', 'payments:initiate:max_500']
// Pass to your agent — it's now authorizedawait travelAgent.run({ grantToken: token.grantToken, task: 'Book cheapest flight to Delhi on March 1' });

5. Record the action at the execution boundary

// At the trusted execution boundary: explicitly record the outcomeawait grantex.audit.log({  agentId: agent.id,  agentDid: agent.did,  grantId: token.grantId,  principalId: authRequest.principalId,  action: 'payment.initiated',  status: 'success',  metadata: { amount: 420, currency: 'USD', merchant: 'Air India' },});

6. Verify a token (service-side)

// In any service that receives agent requests — no Grantex account neededimport { verifyGrantToken } from '@grantex/sdk';
const grant = await verifyGrantToken(token.grantToken, {  jwksUri: 'https://api.grantex.dev/.well-known/jwks.json',  requiredScopes: ['payments:initiate'],});// Throws if the token is expired, tampered with, has invalid claims, or lacks required scopes.// Use grantex.tokens.verify(token.grantToken) when you also need current revocation status.

7. Give users control over their permissions

// Generate a short-lived link for the end-user to view & revoke agent accessconst session = await grantex.principalSessions.create({  principalId: 'user_abc123',  expiresIn: '2h',});// Send session.dashboardUrl to the user via email, in-app notification, etc.// The short-lived session token is carried in the URL fragment, not the query string.

Python SDK

import os
from grantex import Grantex, AuthorizeParams, ExchangeTokenParams
client = Grantex(api_key=os.environ["GRANTEX_API_KEY"])
# Register agentagent = client.agents.register(    name="finance-agent",    scopes=["transactions:read", "payments:initiate:max_100"],)
# Authorize a userauth = client.authorize(AuthorizeParams(    agent_id=agent.id,    user_id="user_abc123",    scopes=["transactions:read", "payments:initiate:max_100"],))# Redirect user to auth.consent_url — they approve in plain language
# Exchange the authorization code for a grant tokentoken = client.tokens.exchange(ExchangeTokenParams(code=code, agent_id=agent.id))
# Verify locally after retrieving the issuer's published JWKSfrom grantex import verify_grant_token, VerifyGrantTokenOptions
grant = verify_grant_token(token.grant_token, VerifyGrantTokenOptions(    jwks_uri="https://api.grantex.dev/.well-known/jwks.json",))print(grant.scopes)  # ('transactions:read', 'payments:initiate:max_100')
# Log an actionclient.audit.log(    agent_id=agent.id,    agent_did=agent.did,    grant_id=token.grant_id,    principal_id=auth.principal_id,    action="transaction.read",    status="success",    metadata={"account_last4": "4242"},)

The Grant Token

Grantex tokens are standard JWTs (RS256) extended with agent-specific claims. Any service can verify their signatures locally using the issuer's published JWKS. The provided verifiers retrieve those keys from the configured JWKS URL, so applications should account for network availability, caching, and key rotation:

{  "iss": "https://grantex.dev",  "sub": "user_abc123",  "agt": "did:grantex:ag_01HXYZ123abc",  "dev": "org_yourcompany",  "scp": ["calendar:read", "payments:initiate:max_500"],  "iat": 1709000000,  "exp": 1709086400,  "jti": "tok_01HXYZ987xyz",  "grnt": "grnt_01HXYZ456def"}

Delegation claims (present on sub-agent tokens):

Multi-Agent Delegation

Grantex supports multi-agent pipelines where a root agent spawns sub-agents with narrower scopes. Sub-agent tokens carry a full delegation chain that any service can inspect.

// Root agent has a grant for ['calendar:read', 'calendar:write', 'email:send']// It spawns a sub-agent that only needs calendar read access
const delegated = await grantex.grants.delegate({  parentGrantToken: rootGrantToken,   // root agent's token  subAgentId: subAgent.id,            // sub-agent to authorize  scopes: ['calendar:read'],          // must be ⊆ parent scopes  expiresIn: '1h',                    // capped at parent token's expiry});
// delegated.grantToken is a fully signed JWT with://   parentAgt, parentGrnt, delegationDepth = 1

# Python equivalentdelegated = grantex.grants.delegate(    parent_grant_token=root_grant_token,    sub_agent_id=sub_agent.id,    scopes=["calendar:read"],    expires_in="1h",)

Constraints enforced by the protocol:

• Sub-agent scopes must be a strict subset of the parent's scopes — scope escalation is rejected with 400
• Sub-agent token expiry is min(parent expiry, requested expiry) — sub-agents can never outlive their parent
• Revoking a root grant cascades to all descendant grants atomically

Advanced Features

// Create an OIDC connectionconst conn = await grantex.sso.createConnection({  name: 'Okta Production',  protocol: 'oidc',  issuerUrl: 'https://mycompany.okta.com',  clientId: 'your-client-id',  clientSecret: 'your-client-secret',  domains: ['mycompany.com'],  jitProvisioning: true,  groupAttribute: 'groups',  groupMappings: { Engineering: ['read', 'write', 'deploy'], Admins: ['admin'] },  defaultScopes: ['read'],});
// Create a SAML 2.0 connectionawait grantex.sso.createConnection({  name: 'Azure AD SAML',  protocol: 'saml',  idpEntityId: 'https://sts.windows.net/tenant-id/',  idpSsoUrl: 'https://login.microsoftonline.com/tenant-id/saml2',  idpCertificate: '-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----',  spEntityId: 'urn:grantex:mycompany',  spAcsUrl: 'https://myapp.com/sso/callback/saml',  domains: ['mycompany.com'],});
// Enforce SSO for the organization// First complete an OIDC login that maps an administrator to the admin scope.// The server must have SSO_HUMAN_ENFORCEMENT_ENABLED=true.await grantex.sso.setEnforcement({ enforce: true });
// Handle OIDC callback with verified ID tokenconst result = await grantex.sso.handleOidcCallback({ code, state });console.log(result.email, result.mappedScopes, result.sessionId);// result.sessionToken is an opaque bearer credential when enabled. Keep it secret.
// List and revoke sessionsconst { sessions } = await grantex.sso.listSessions();await grantex.sso.revokeSession(sessions[0].id);

# Create an OIDC connectionconn = client.sso.create_connection(CreateSsoConnectionParams(    name="Okta Production",    protocol="oidc",    issuer_url="https://mycompany.okta.com",    client_id="your-client-id",    client_secret="your-client-secret",    domains=["mycompany.com"],    jit_provisioning=True,    group_attribute="groups",    group_mappings={"Engineering": ["read", "write", "deploy"]},))
# Handle OIDC callbackresult = client.sso.handle_oidc_callback(SsoOidcCallbackParams(code=code, state=state))print(result.email, result.mapped_scopes, result.session_id)

# Create a connectiongrantex sso connections create --name "Okta" --protocol oidc \  --issuer-url https://mycompany.okta.com \  --client-id $CLIENT_ID --client-secret $CLIENT_SECRET \  --domains mycompany.com --jit-provisioning
# List connectionsgrantex sso connections list
# Test connectivitygrantex sso connections test sso_01HXYZ...
# Enforce SSOgrantex sso enforce --enable

// Enable FIDO for your developer accountawait grantex.updateSettings({ fidoRequired: true, fidoRpName: 'My App' });
// Server-side, after authenticating the end customer:const { enrollmentUrl } = await grantex.webauthn.createEnrollmentSession({  principalId: authenticatedCustomer.grantexPrincipalId,});// Show the one-use link only to that customer. The hosted page handles WebAuthn.
// List and manage credentialsconst { credentials: creds } = await grantex.webauthn.listCredentials('user_abc123');await grantex.webauthn.deleteCredential(credentialId);

# Enable FIDO for your developer accountfrom grantex import UpdateDeveloperSettingsParams
client.update_settings(UpdateDeveloperSettingsParams(    fido_required=True,    fido_rp_name="My App",))
# After your app authenticates the customer, issue a one-use hosted link.session = client.webauthn.create_enrollment_session(principal_id="user_abc123")enrollment_url = session.enrollment_url
# List and manage credentialscreds = client.webauthn.list_credentials("user_abc123").credentialsclient.webauthn.delete_credential(credential_id)

const result = await grantex.tokens.exchange({  code,  agentId: agent.id,  credentialFormat: 'vc-jwt',   // opt-in to VC issuance});
console.log(result.grantToken);         // standard RS256 JWT (unchanged)console.log(result.verifiableCredential); // W3C VC-JWT

result = client.tokens.exchange(ExchangeTokenParams(    code=code,    agent_id=agent.id,    credential_format="vc-jwt",))
print(result.verifiable_credential)  # W3C VC-JWT

const verification = await grantex.credentials.verify(vcJwt);console.log(verification.valid);console.log(verification.credentialSubject);console.log(verification.issuer); // "did:web:grantex.dev"

verification = client.credentials.verify(vc_jwt)print(verification.valid)print(verification.credential_subject)

// Check a specific credential's statusconst cred = await grantex.credentials.get(credentialId);console.log(cred.status); // "active" or "revoked"
// List credentials with filtersconst { credentials } = await grantex.credentials.list({  grantId: 'grnt_01HXYZ...',  status: 'active',});

curl https://api.grantex.dev/.well-known/did.json

import { Grantex } from '@grantex/sdk';
const grantex = new Grantex({ apiKey: process.env.GRANTEX_API_KEY });
const passport = await grantex.passports.issue({  agentId: 'ag_01HXYZ...',  grantId: 'grnt_01HXYZ...',  allowedMPPCategories: ['inference', 'compute'],  maxTransactionAmount: { amount: 50, currency: 'USDC' },  paymentRails: ['tempo'],  expiresIn: '24h',});// passport.passportId   → "urn:grantex:passport:01HXYZ..."// passport.encodedCredential → base64url for X-Grantex-Passport header

curl -X POST https://api.grantex.dev/v1/passport/issue \  -H "Authorization: Bearer $GRANTEX_API_KEY" \  -H "Content-Type: application/json" \  -d '{    "agentId": "ag_01HXYZ...",    "grantId": "grnt_01HXYZ...",    "allowedMPPCategories": ["inference", "compute"],    "maxTransactionAmount": { "amount": 50, "currency": "USDC" },    "expiresIn": "24h"  }'

import { createMppPassportMiddleware } from '@grantex/mpp';
const middleware = createMppPassportMiddleware({ passport });const enrichedRequest = await middleware(new Request(url, init));// enrichedRequest now has X-Grantex-Passport headerconst response = await fetch(enrichedRequest);

import { verifyPassport } from '@grantex/mpp';
const verified = await verifyPassport(encodedCredential, {  requiredCategories: ['inference'],  maxAmount: 10,});// verified.humanDID        → "did:grantex:user_alice"// verified.organizationDID → "did:web:acme.com"// verified.allowedCategories → ["inference", "compute"]// verified.maxTransactionAmount → { amount: 50, currency: "USDC" }

import { requireAgentPassport } from '@grantex/mpp';
app.use('/api/inference', requireAgentPassport({  requiredCategories: ['inference'],  maxAmount: 10,}));// req.agentPassport is populated on valid requests// 403 with typed error code on invalid requests

import { requirePayment } from '@grantex/mpp';
app.get('/api/report', requirePayment({  secret: process.env.PAYMENT_CHALLENGE_SECRET!,  realm: 'api.merchant.example',  offers: () => [{ method: 'tempo', intent: 'charge', request: { amount: '1000', currency: 'usd' } }],  verifyPayload: async (credential) => verifyWithYourPaymentMethod(credential.payload),}), handler);// 402 with WWW-Authenticate challenges; on a valid credential, Payment-Receipt and req.payment

curl https://api.grantex.dev/v1/trust-registry/did:web:grantex.dev# {"organizationDID":"did:web:grantex.dev","trustLevel":"soc2","domains":["grantex.dev"]}

import { lookupOrgTrust } from '@grantex/mpp';
const record = await lookupOrgTrust('did:web:acme.com');// record.trustLevel → "verified" | "soc2" | "basic"// record.verificationMethod → "dns-txt" | "manual" | "soc2"

await grantex.passports.revoke('urn:grantex:passport:01HXYZ...');// Revocation-aware verification rejects after checking refreshed status data

const result = await grantex.tokens.exchange({  code,  agentId: agent.id,  credentialFormat: 'sd-jwt',   // opt-in to SD-JWT issuance});
console.log(result.grantToken);         // standard RS256 JWT (unchanged)console.log(result.sdJwt);              // SD-JWT with selective disclosure

result = client.tokens.exchange(ExchangeTokenParams(    code=code,    agent_id=agent.id,    credential_format="sd-jwt",))
print(result.sd_jwt)  # SD-JWT with selective disclosure

const presentation = await grantex.credentials.present({  sdJwt: result.sdJwt,  disclosedClaims: ['scopes', 'agentId'],   // only reveal these fields});
// Send presentation to the verifier — they see scopes and agentId,// but principalId, developerId, grantId, etc. remain hidden

presentation = client.credentials.present(    sd_jwt=result.sd_jwt,    disclosed_claims=["scopes", "agent_id"],)

// Allocate a budget to a grantconst budget = await grantex.budgets.allocate({  grantId: 'grnt_01HXYZ...',  amount: 1000,  currency: 'USD',});
// Debit against the budgetconst debit = await grantex.budgets.debit({  grantId: 'grnt_01HXYZ...',  amount: 42.50,  description: 'Flight booking',});console.log(debit.remaining); // 957.50
// Check the current balanceconst balance = await grantex.budgets.balance('grnt_01HXYZ...');console.log(balance.remainingBudget);
// List all budget transactions for a grantconst { transactions } = await grantex.budgets.transactions('grnt_01HXYZ...');

# Allocate a budget to a grantbudget = client.budgets.allocate(    grant_id="grnt_01HXYZ...",    amount=1000,    currency="USD",)
# Debit against the budgetdebit = client.budgets.debit(    grant_id="grnt_01HXYZ...",    amount=42.50,    description="Flight booking",)print(debit.remaining)  # 957.50
# Check the current balancebalance = client.budgets.balance("grnt_01HXYZ...")
# List all budget transactionstransactions = client.budgets.transactions("grnt_01HXYZ...")

// SSE — async generator, automatically reconnectsfor await (const event of grantex.events.stream()) {  console.log(event.type);   // 'grant.created', 'token.issued', etc.  console.log(event.data);}
// Convenience wrapper with a callbackgrantex.events.subscribe((event) => {  if (event.type === 'budget.threshold') {    alert(`Grant ${event.data.grantId} is at ${event.data.percentage}% budget`);  }});

# SSE — async generatorasync for event in client.events.stream():    print(event.type)   # 'grant.created', 'grant.revoked', etc.    print(event.data)
# Convenience wrapperasync def handler(event):    if event.type == "budget.exhausted":        await revoke_grant(event.data["grant_id"])
await client.events.subscribe(handler)

// Get current period usageconst usage = await grantex.usage.current();console.log(usage.tokenExchanges);console.log(usage.authorizations);console.log(usage.totalRequests);
// Get usage history over the last 30 daysconst { entries } = await grantex.usage.history({ days: 30 });entries.forEach((e) => console.log(`${e.date}: ${e.totalRequests} requests`));

# Get current period usageusage = client.usage.current()print(usage.token_exchanges)print(usage.total_requests)
# Get usage history over the last 30 dayshistory = client.usage.history(days=30)for entry in history.entries:    print(f"{entry.date}: {entry.total_requests} requests")

// Register a custom domainconst domain = await grantex.domains.create({ domain: 'auth.yourapp.com' });console.log(domain.verificationToken);// → Add a DNS TXT record: _grantex-verify.auth.yourapp.com = <token>
// Verify the domain after adding the DNS recordconst verified = await grantex.domains.verify(domain.id);console.log(verified.verified); // true
// List all registered domainsconst { domains } = await grantex.domains.list();
// Delete a domainawait grantex.domains.delete(domain.id);

# Register a custom domaindomain = client.domains.create(domain="auth.yourapp.com")print(domain.verification_token)
# Verify after adding DNS TXT recordverified = client.domains.verify(domain.id)print(verified.verified)  # True
# List all domainsdomains = client.domains.list()
# Delete a domainclient.domains.delete(domain.id)

// Upload a policy bundleawait grantex.policies.sync({  format: 'opa',           // 'opa' or 'cedar'  bundle: bundleBuffer,    // policy bundle as Buffer});
// List policy bundlesconst { bundles } = await grantex.policies.bundles();

# Upload a policy bundleclient.policies.sync(    format="opa",    bundle=bundle_bytes,)
# List policy bundlesbundles = client.policies.bundles()

import { Grantex } from '@grantex/sdk';
const grantex = new Grantex({ apiKey: process.env.GRANTEX_API_KEY });
// Register a consent notice versionconst notice = await grantex.dpdp.createConsentNotice({  noticeId: 'privacy-v1',  version: '1.0',  title: 'Data Processing Notice',  content: 'We process your data for...',  purposes: [{ code: 'analytics', description: 'Usage analytics' }],});
// Record consent against an existing, active grantconst record = await grantex.dpdp.createConsentRecord({  grantId: 'grnt_01HXYZ...',  dataPrincipalId: '[email protected]',  purposes: [{ code: 'analytics', description: 'Usage analytics' }],  consentNoticeId: 'privacy-v1',  processingExpiresAt: '2027-01-01T00:00:00Z',});
// Records held about a principal, for an access request (DPDP s.11)const { records } = await grantex.dpdp.listPrincipalRecords('[email protected]');
// Withdraw consent (s.6(4)); optionally revoke the grant and ask your// application, by webhook, to delete the data it processedconst withdrawal = await grantex.dpdp.withdrawConsent(record.recordId, {  reason: 'No longer needed',  revokeGrant: true,  deleteProcessedData: true,});
// Record a grievance (DPDP s.13)const grievance = await grantex.dpdp.fileGrievance({  dataPrincipalId: '[email protected]',  type: 'unauthorized-processing',  description: 'Data used beyond the consented purpose',});
// Act on an erasure request (DPDP s.12)const erasure = await grantex.dpdp.requestErasure('[email protected]');
// Generate a DPDP audit exportconst report = await grantex.dpdp.createExport({  type: 'dpdp-audit',  dateFrom: '2026-01-01T00:00:00Z',  dateTo: '2026-04-01T00:00:00Z',});

# Python SDKfrom grantex import CreateConsentRecordParams, Grantex
client = Grantex(api_key="gx_...")
record = client.dpdp.create_consent_record(CreateConsentRecordParams(    grant_id="grnt_01HXYZ...",    data_principal_id="[email protected]",    purposes=[{"code": "analytics", "description": "Usage analytics"}],    consent_notice_id="privacy-v1",    processing_expires_at="2027-01-01T00:00:00Z",))records = client.dpdp.list_principal_records("[email protected]")erasure = client.dpdp.request_erasure("[email protected]")

Scope Enforcement

Enforce tool-level permissions on any connector — define your own manifests or use the 53 pre-built ones.

Quick Start

from grantex import Grantex, ToolManifest, Permission
grantex = Grantex(api_key="gx_...")
# Define a manifest for any connector — yours, not oursgrantex.load_manifest(ToolManifest(    connector="my-crm",    tools={"search": Permission.READ, "create_deal": Permission.WRITE, "delete_account": Permission.DELETE},))
result = grantex.enforce(grant_token=token, connector="my-crm", tool="delete_account")# result.allowed = False — "write scope does not permit delete operations"

Permission Hierarchy

Bring your own manifests: define inline, load from JSON files, load from a directory, or auto-generate from source code via CLI. 53 pre-built manifests included: Salesforce, HubSpot, Jira, Stripe, SAP, S3, Gmail, Slack, GitHub, and 44 more — use as-is or as a starting point.

Framework helpers: wrapTool() wraps LangChain tools with automatic scope enforcement. createGrantexTool() covers TypeScript agent framework helpers including Strands Agents SDK. create_grantex_tool() covers Python OpenAI Agents SDK, Google ADK, and Strands Agents SDK tools. enforceMiddleware() adds one-line enforcement to Express/Fastify routes. FastAPI uses the GrantexEnforcer dependency.

See the Scope Enforcement Guide for full documentation.

Local Development

Use Node.js 24 LTS for repository installs, builds and tests. The upgraded Vitest 5 toolchain needs Node.js 22.12 or newer; this contributor requirement is separate from the runtime requirements of an already published SDK. Use the checked-in lockfiles with npm ci and see CONTRIBUTING.md.

Start the full stack with one command:

git clone https://github.com/mishrasanjeev/grantex.gitcd grantexdocker compose up --build

Two API keys are seeded automatically:

Sandbox mode is designed for testing. With a sandbox key and fidoRequired: false (the default), POST /v1/authorize returns a code in the response body — no redirect required. Set fidoRequired: true to rehearse the real enrollment and consent ceremony instead:

# Authorize + get code in one stepcurl -s -X POST http://localhost:3001/v1/authorize \  -H "Authorization: Bearer sandbox-api-key-local" \  -H "Content-Type: application/json" \  -d '{"agentId":"<id>","principalId":"test-user","scopes":["calendar:read"]}'# → { ..., "sandbox": true, "code": "01J..." }
# Exchange immediately for a grant tokencurl -s -X POST http://localhost:3001/v1/token \  -H "Authorization: Bearer sandbox-api-key-local" \  -H "Content-Type: application/json" \  -d '{"code":"<code>","agentId":"<id>"}'

Developer portal is available at grantex.dev/dashboard — sign up or enter an API key to manage agents, grants, policies, anomalies, compliance exports, and billing from the browser.

Account settings for live consent and irregularities: The Billing page shows your account's actual plan. The source limits are 1,000 active grants on Free, 50,000 on Pro, and unlimited on Enterprise, counted across the developer account rather than per agent. Check the deployed account with authenticated GET /v1/billing/subscription; an agent ID alone cannot reveal its plan. The Irregularities page offers an account-wide alert_only response to findings from POST /v1/anomalies/detect when IRREGULARITY_RESPONSE_POLICY_ENABLED=true. Without that server flag, the detector retains its existing agent-wide revocation of active grants on high/critical findings. Alert-only preserves alerts and does not bypass manual revocation or independent security gates. See the setup guide. Server availability depends on deployment and rollout flags. TypeScript @grantex/[email protected], Python grantex==0.7.2, and Go v0.4.3 publish the client methods.

For local development, the auth service also serves a lightweight dashboard at http://localhost:3001/dashboard.

See the self-hosting guide for production deployment guidance, or DEPLOYMENT.md for the complete deployment reference (system requirements, environment variables, Docker/Kubernetes/Cloud Run options, security checklist, monitoring). Python dependencies are in requirements.txt.

Why an Open Standard?

Grantex is built as an open protocol, not a closed SaaS product. Here's why that matters:

Model-neutral. Grantex operates at the SDK or protected-service boundary rather than depending on one model provider. The project documents use with OpenAI, Anthropic, Google, Llama, and Mistral models.

Framework-native. First-class integrations for LangChain, AutoGen, CrewAI, OpenAI Agents SDK, Google ADK, Strands Agents SDK, and plain code. Install one package, get Grantex in your existing stack.

Offline-verifiable signatures. Services verify token signatures locally using published JWKS. Applications should plan for JWKS retrieval and key rotation; availability during an issuer outage depends on their verifier's cache behavior.

Compliance-oriented controls. The EU AI Act, GDPR, and emerging AI regulations increasingly expect records of what automated systems did and who authorised it. Grantex provides technical controls that can support those programs from day one.

Scope Naming Convention

Grantex defines a standard scope format: resource:action[:constraint]

Service providers implement scope definitions for their APIs. Agents declare which scopes they need. Users see plain-language descriptions, never raw scope strings.

Integrations

This table is a source-and-registry status snapshot as of 2026-09-07; the primary SDK rows follow the release snapshot verified 2026-09-29. For integration packages, "Published package" identifies a public package surface; check its registry page and compatibility notes before choosing a version.

The guarded publish-primary-sdks.yml workflow builds and tests each prepared version once, then publishes those immutable artifacts. Before it can publish, a maintainer must configure the protected sdk-release GitHub environment, npm trusted-publisher records for both npm packages, a PyPI trusted publisher for grantex, and a narrowly scoped Go-repository release token. A manifest version bump by itself is not a release.

Community x402 services

• JMT x402 Agent Tools provides paid Base-mainnet tools for search, analysis, market data, filings, company intelligence, and news. Query its discovery endpoint for the current tool catalog and pricing.

Framework Quick Examples

Express.js — grant token verification + scope-based authorization:

import express from 'express';import { requireGrantToken, requireScopes } from '@grantex/express';
const JWKS_URI = 'https://api.grantex.dev/.well-known/jwks.json';
app.use('/api', requireGrantToken({ jwksUri: JWKS_URI }));app.get('/api/calendar', requireScopes('calendar:read'), (req, res) => {  res.json({ principalId: req.grant.principalId, scopes: req.grant.scopes });});

FastAPI — dependency injection with scope enforcement:

from fastapi import Depends, FastAPIfrom grantex import VerifiedGrantfrom grantex_fastapi import GrantexAuth, GrantexFastAPIError, grantex_exception_handler
app = FastAPI()app.add_exception_handler(GrantexFastAPIError, grantex_exception_handler)grantex = GrantexAuth(jwks_uri="https://api.grantex.dev/.well-known/jwks.json")
@app.get("/api/calendar")async def calendar(grant: VerifiedGrant = Depends(grantex.scopes("calendar:read"))):    return {"principalId": grant.principal_id}

LangChain — scope-enforced tools + audit callbacks:

import { createGrantexTool } from '@grantex/langchain';
const tool = createGrantexTool({  name: 'read_calendar',  description: 'Read upcoming calendar events',  grantToken,  requiredScope: 'calendar:read',  func: async (input) => JSON.stringify(await getCalendarEvents(input)),});// Use with any LangChain agent — signature and scope checked locally using JWKS

Vercel AI SDK — scope checked at construction time:

import { createGrantexTool } from '@grantex/vercel-ai';import { z } from 'zod';
const tool = createGrantexTool({  name: 'read_calendar',  description: 'Read upcoming calendar events',  parameters: z.object({ date: z.string() }),  grantToken,  requiredScope: 'calendar:read',  execute: async (args) => await getCalendarEvents(args.date),});// Use with generateText, streamText, etc.

AutoGen / OpenAI function calling:

import { createGrantexFunction, GrantexFunctionRegistry } from '@grantex/autogen';
const fn = createGrantexFunction({  name: 'read_calendar',  description: 'Read upcoming calendar events',  parameters: { type: 'object', properties: { date: { type: 'string' } }, required: ['date'] },  grantToken,  requiredScope: 'calendar:read',  func: async (args) => await getCalendarEvents(args.date),});
// Pass fn.definition to OpenAI, call fn.execute() when selected

CrewAI (Python):

from grantex_crewai import GrantexTool
tool = GrantexTool(    name="read_calendar",    description="Read upcoming calendar events",    grant_token=grant_token,    required_scope="calendar:read",    func=get_calendar_events,)# Use with any CrewAI agent

OpenAI Agents SDK (Python):

from grantex_openai_agents import create_grantex_tool
tool = create_grantex_tool(    name="read_calendar",    description="Read upcoming calendar events",    grant_token=grant_token,    required_scope="calendar:read",    func=get_calendar_events,)# Returns a FunctionTool — use with any OpenAI Agents SDK agent

Google ADK (Python):

from grantex_adk import create_grantex_tool
read_calendar = create_grantex_tool(    name="read_calendar",    description="Read upcoming calendar events",    grant_token=grant_token,    required_scope="calendar:read",    func=get_calendar_events,)# Returns a plain function — pass directly to google.adk.Agent(tools=[...])

Strands Agents SDK (Python):

from grantex_strands import create_grantex_tool
read_calendar = create_grantex_tool(    name="read_calendar",    description="Read upcoming calendar events",    grant_token=grant_token,    required_scope="calendar:read",    func=get_calendar_events,)# Returns a Strands-compatible tool — pass into your Strands agent tools list

CLI (90+ commands, all support --json for AI agent / scripting use):

grantex config set --url https://api.grantex.dev --key YOUR_API_KEYgrantex me                                            # check identitygrantex agents register --name "Bot" --description "..." --scopes email:readgrantex agents update ag_... --redirect-uri https://client.example/grants/callbackgrantex authorize --agent ag_... --principal [email protected] --scopes email:readgrantex tokens exchange --code <code> --agent-id ag_...grantex tokens verify <jwt>grantex tokens refresh --refresh-token <token> --agent-id ag_...grantex grants delegate --grant-token <jwt> --agent-id ag_child... --scopes email:readgrantex budgets allocate --grant-id grnt_... --amount 100grantex audit list --agent ag_...grantex grants revoke grnt_...
# DPDP Act 2023 records (11 subcommands)grantex dpdp consent create --grant-id grnt_... --principal-id [email protected]   --notice-id privacy-v1 --processing-expires-at 2027-01-01T00:00:00Z   --purposes '[{"code":"analytics","description":"Usage analytics"}]'grantex dpdp consent get <recordId>grantex dpdp consent list --principal [email protected]grantex dpdp consent withdraw <recordId> --reason "No longer needed"# Create a consent notice with the released --notice-version option:grantex dpdp notices create --notice-id privacy-v1 --notice-version 1.0 --title "Privacy Notice" --content "We process your data for..." --purposes '[{"code":"analytics","description":"Usage analytics"}]'grantex dpdp grievances file --principal-id [email protected] --type unauthorized-processing   --description "Data used beyond the consented purpose"grantex dpdp grievances get <grievanceId>grantex dpdp erasure [email protected]grantex dpdp exports create --type dpdp-audit --date-from 2026-01-01 --date-to 2026-04-01grantex dpdp exports get <exportId>grantex dpdp principal-records [email protected]
# Machine-readable output for scripts and AI coding assistantsgrantex --json agents list | jq '.[0].agentId'

Interactive Playground

Try the full Grantex authorization flow live in your browser — no signup required:

grantex.dev/playground

Walk through all 7 steps of the protocol: register an agent, authorize, exchange tokens, verify, refresh, revoke, and verify revocation. Uses sandbox mode with your API key.

Examples

Architecture

┌──────────────────────────────────────────────────────────────────────┐│                         YOUR APPLICATION                             ││                                                                      ││   ┌──────────────┐    ┌──────────────┐    ┌───────────────────────┐ ││   │  AI Agent    │    │  Grantex SDK │    │  End User Dashboard   │ ││   │  (any model) │◄──►│  (2 lines)   │    │  (view / revoke)      │ ││   └──────────────┘    └──────┬───────┘    └───────────────────────┘ │└──────────────────────────────┼───────────────────────────────────────┘                               │ HTTPS                               ▼┌──────────────────────────────────────────────────────────────────────┐│                         GRANTEX PROTOCOL                             ││                                                                      ││  ┌─────────────┐  ┌──────────────┐  ┌─────────────┐  ┌──────────┐  ││  │  Identity   │  │     Auth     │  │   Consent   │  │  Audit   │  ││  │  Service    │  │   Service    │  │     UI      │  │  Chain   │  ││  │  (DID/JWKS) │  │ (token i/o)  │  │  (hosted)   │  │ (append) │  ││  └─────────────┘  └──────────────┘  └─────────────┘  └──────────┘  │└──────────────────────────────────────────────────────────────────────┘                               │                               ▼                ┌──────────────────────────┐                │  Any Service / API       │                │  Verifies via JWKS       │                │  No Grantex dep needed   │                └──────────────────────────┘

Product Roadmap

The current product roadmap prioritizes a 2026.08 production-trust baseline: durable MCP authorization, primary-SDK parity and release safety, revocation-aware enforcement, plan throughput, and production Commerce consent. Repository progress is recorded under Unreleased; the release-status guide, compatibility matrix, and package-specific documentation remain authoritative for published versions, deployment status, and limitations. The labels below are historical source milestones, not release or production-readiness claims.

Contributing

Grantex welcomes contributions. CONTRIBUTING.md explains the contribution licence that lets Orchestrum Technologies LLP license contributions, including commercially:

1. Report bugs — open a GitHub Issue with reproduction steps
2. Propose features — open a GitHub Discussion with your use case
3. Build new integrations — add Grantex support to your favorite framework
4. Improve docs — better examples, tutorials, and translations

Read CONTRIBUTING.md before submitting a PR.

Standards & Compliance

Full compliance matrix: docs.grantex.dev/guides/compliance-matrix

Trusted By

Using Grantex under a commercial agreement with Orchestrum? Write to [email protected] to be listed here.

FAQ

Is this just another auth library?
Human identity systems and Grantex solve different layers. Human auth establishes who the person is; Grantex carries the scoped authority that person or organization delegated to a specific agent. Current revocation requires an online state check or synchronized revocation data at the enforcement point.

Why not just use OAuth 2.0?
OAuth 2.0 was designed for "user grants app permission to access their data." Agents introduce new requirements: the agent needs a verifiable identity separate from its creator, grants need to be chainable across multi-agent pipelines, and every autonomous action must be attributable and auditable. We extend OAuth 2.0 concepts but add the agent-specific primitives it lacks.

What about MCP (Model Context Protocol)?
MCP connects clients to tools and resources and defines optional OAuth-based authorization for HTTP transports. Grantex adds agent-specific delegated authority at the tool or service boundary: which agent may perform which action for which principal. The two layers are complementary.

Who owns the standard?
The v1.0 protocol specification is published in this repository under the Orchestrum Personal Use License 1.0. Grantex is owned by Orchestrum Technologies LLP, and Sanjeev Kumar is listed as inventor and owner. Orchestrum Technologies LLP maintains the reference implementation. Revision -02 is published as an active individual IETF Internet-Draft, and revision -03 is under review; neither publication nor repository implementation is working-group adoption, independent certification, or IETF endorsement.

Can I self-host?
Yes. The SDKs are Apache-2.0 and free for any use. The auth service and portal are under the Orchestrum Personal Use License 1.0: an individual may self-host them for their own personal use, and self-hosting by or for any organisation, including evaluation and pilots, needs prior written permission from Orchestrum Technologies LLP (see Licence). Docker Compose deploy in one command. See DEPLOYMENT.md for the complete guide or the self-hosting docs.

License

SDKs and client packages (packages/) and examples (examples/): Apache-2.0, open source and free for any use. Auth service, portal, specification text, documentation and website: Orchestrum Personal Use License 1.0, licensor Orchestrum Technologies LLP; free only for an individual's personal use, and any organisation needs prior written permission from Orchestrum Technologies LLP (COMMERCIAL-LICENSE.md, [email protected]). Directory scope: LICENSING.md. Trademarks: TRADEMARKS.md.

Third-party packages and the third-party files listed in THIRD_PARTY_NOTICES.md retain their own licenses. Review that file before redistribution.

Product ownership: Grantex is owned by Orchestrum Technologies LLP. Inventor and owner: Sanjeev Kumar. Ownership contact: [email protected] or [email protected].