What Sardis Is

Sardis is the open-source financial authority layer for AI agents. It sits between autonomous agents and money-moving systems so every consequential financial action is checked against a mandate, policy decision, approval path, revocation path, and audit packet before execution.

Sardis is not a card wrapper, prepaid wallet, or rail-specific payment app. It governs the authority to spend across stablecoin wallets, card programs, fiat payment APIs, x402-style HTTP payments, AP2/TAP mandates, provider-hosted wallets, and simulator rails.

The core primitive is verifiable authority before an agent can spend, subscribe, purchase, refund, settle, or trigger paid usage. Customers can bring their own providers; Sardis enforces the authority layer above them without needing to custody funds or become the merchant of record.

The deeper thesis is that agents do not just have a capability problem; they have a trust problem. Sardis treats money as the sharpest version of a broader substrate problem: how non-human actors perform consequential actions with explicit authority, reviewable state transitions, and durable evidence.

Read the boundaries:

• Open-core model
• Provider abstraction
• OSS goal
• Public/private boundary
• Package maturity matrix
• Legal and compliance disclaimer
• Agent authority demo

📦 Quick Install

# MCP Server (Claude, Cursor, ChatGPT)
npx @sardis/mcp-server start

# Python SDK
pip install sardis

# TypeScript SDK
npm install @sardis/sdk

# LangChain
pip install sardis  # Uses sardis-sdk under the hood

# CrewAI
pip install sardis  # Compatible with CrewAI tools

# OpenAI Functions
pip install sardis  # Use with OpenAI function calling

# Gemini / ADK
pip install sardis  # Compatible with Google AI SDKs

# Vercel AI SDK
npm install @sardis/ai-sdk

What Problems Sardis Solves

AI agents can draft invoices, call paid APIs, buy tools, book travel, issue refunds, subscribe to services, and interact with merchants. The missing layer is not only "payments." It is the authority system that decides whether the agent was allowed to do the financial action in the first place.

Sardis provides:

• Mandates -- who delegated authority to the agent, for what scope, under which limits.
• Policy firewall -- deterministic checks before execution or signing.
• Approvals -- step-up flows for high-risk, high-value, or ambiguous actions.
• Revocation -- stop future execution when authority changes.
• Provider adapters -- route approved actions to wallets, cards, stablecoins, payment APIs, or simulators.
• Audit packets -- immutable evidence for operators, customers, partners, and reviewers.

Sardis can route approved actions to provider adapters. Live-money deployments depend on the configured provider account, jurisdiction, compliance program, and customer policy.

Protocol & Feature Maturity

Status key: Implemented = code and tests exist in the public repository. Pilot = functional with conservative limits and active hardening. Experimental = code exists, not production-tested.

Key Features

• Provider-neutral authority layer -- govern cards, wallets, stablecoins, payment APIs, x402, AP2, TAP, and simulator rails
• Mandates and spending policy -- "Max $50/tx, $200/day, SaaS vendors only"
• Pre-execution policy firewall -- fail-closed checks before signing, issuing, paying, refunding, or settling
• Approval and revocation flows -- step-up before risky actions, kill switch when authority changes
• Provider adapter contract -- capability declarations, idempotency, signed webhooks, revocation windows, audit fields
• 15+ AI framework integrations -- LangChain, CrewAI, OpenAI Agents, Claude SDK, Google ADK, A2A, AgentKit, Vercel AI SDK, MCP, and more
• Agent-to-agent escrow -- Cryptographic mandate chain for A2A payments
• KYA (Know Your Agent) -- Trust scoring and behavioral anomaly detection
• Double-entry audit ledger -- Append-only transaction history with cryptographic proofs
• Protocol support -- AP2 and TAP (production), x402 (pilot), UCP and A2A (partial)

🚀 Quick Start

Python (5 lines)

from sardis import SardisClient

client = SardisClient(api_key="sk_...")
result = client.pay(
    to="[email protected]",
    amount="50.00",
    currency="USDC",
    chain="base",
)
print(f"Payment: {result.tx_hash}")

TypeScript

import { SardisClient } from '@sardis/sdk';

const client = new SardisClient({ apiKey: 'sk_...' });
const agent = await client.agents.create({ name: 'my-agent' });
const wallet = await client.wallets.create({
  agent_id: agent.agent_id,
  currency: 'USDC',
  limit_per_tx: '100.00',
});
const tx = await client.wallets.transfer(wallet.wallet_id, {
  destination: '0x...',
  amount: '25.00',
  token: 'USDC',
  chain: 'base_sepolia',
  domain: 'openai.com',
});

MCP (Claude Desktop / Cursor)

Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "sardis": {
      "command": "npx",
      "args": ["@sardis/mcp-server", "start"]
    }
  }
}

That's it. Your agent now has a bounded financial authority surface instead of unconstrained payment access.

🎯 Framework Integrations

All frameworks use the same policy engine, mandate model, provider adapters, and audit semantics.

Architecture

Every financial action follows a single authority path before execution. There are no alternative code paths that bypass policy checks.

                         AI AGENT
              (Claude, Cursor, LangChain, OpenAI)
                          |
                     MCP / SDK
                          |
            ┌─────────────┴─────────────┐
            │  FinancialActionOrchestrator│
            │    (single entry point)    │
            └─────────────┬─────────────┘
                          |
            ┌─────────────┴─────────────┐
            │   PreExecutionPipeline    │
            │                           │
            │  Composable hooks:        │
            │  - Policy evaluation      │
            │  - Spend tracking         │
            │  - Dedup check            │
            │  - Compliance gate        │
            │  - KYA trust scoring      │
            │                           │
            │  Fail-closed: any hook    │
            │  failure blocks the tx    │
            └─────────────┬─────────────┘
                          |
            ┌─────────────┴─────────────┐
            │   PROVIDER ADAPTER        │
            │   Cards / wallets / APIs  │
            └─────────────┬─────────────┘
                          |
               +──────────┴──────────+
               |                     |
         Stablecoin Rails      Fiat / Card Rails
         Wallet providers      Payment providers
         x402 / AP2 / TAP      BYO provider acct
               |                     |
         ┌─────┴─────┐         ┌────┴────┐
         │  LEDGER   │         │  LEDGER │
         │  Append   │         │  Append │
         │  Only     │         │  Only   │
         └───────────┘         └─────────┘

Key design principles:

• Fail-closed -- Default deny on all policy, compliance, and security checks
• Provider-neutral -- Sardis governs execution without requiring one custody, wallet, card, or payment provider
• Audit everything -- Append-only ledger with signed attestation envelopes for every decision

📂 Repository Structure

sardis/
├── apps/api/               # FastAPI reference API implementation
├── apps/landing/           # Public website source
├── apps/canvas-site/       # Technical canvas source
├── packages/               # Core monorepo packages
│   ├── sardis-core/        # Domain models, config, database
│   ├── sardis-chain/       # Blockchain execution, chain routing
│   ├── sardis-protocol/    # AP2/TAP protocol verification
│   ├── sardis-wallet/      # Wallet management, MPC
│   ├── sardis-ledger/      # Append-only audit trail
│   ├── sardis-compliance/  # KYC (iDenfy) + AML (Elliptic)
│   ├── sardis-cards/       # Card provider adapter experiments
│   ├── sardis-mcp-server/  # MCP server for Claude/Cursor
│   ├── sardis-sdk-python/  # Full Python SDK
│   ├── sardis-sdk-js/      # TypeScript SDK
│   ├── sardis-cli/         # Command-line tool
│   └── sardis-checkout/    # Merchant checkout flows
├── src/sardis/             # Simple Python SDK (public interface)
├── contracts/              # Solidity smart contracts
│   └── src/
│       ├── SardisWalletFactory.sol
│       ├── SardisAgentWallet.sol
│       └── SardisEscrow.sol
├── playground/             # Interactive demo sandbox
├── examples/               # Usage examples
├── demos/                  # Demo applications
├── docs/                   # Public technical documentation
└── tests/                  # Legacy root migration backlog; prefer package tests

📚 Documentation

• Getting Started Guide — First payment in 5 minutes
• API Reference — Complete endpoint documentation
• MCP Server Setup — Claude Desktop integration
• Policy Language — Write spending rules in plain English
• Chain Support — Supported networks and tokens
• Framework Guides — LangChain, OpenAI, Vercel AI SDK
• Security Model — MPC architecture and threat model
• Compliance — KYC/AML/SAR framework
• Examples — Code samples for all frameworks
• Package Maturity Matrix — What is core, supported, experimental, demo, or private-candidate
• Architecture Package Layout — Why repo package paths and Python import namespaces are separate
• OSS Package Layout Policy — Contributor-facing naming, nesting, and rename rules
• Source Layout Policy — API source-tree guardrails and route placement rules
• x402 and MPP Boundary — How paid HTTP protocol surfaces split across packages
• SDK Package Boundary — Official SDKs versus framework-specific agent integrations
• Connect Package Boundary — Python FastAPI versus TypeScript Node/Express Connect ownership
• OpenAI Package Boundary — OpenAI API tool calling versus OpenAI Agents SDK ownership
• Contribution Map — Which package to change, what to contribute, and how to validate it
• Development Guide — Local setup and contribution checks
• Public CI/CD Map — Which public checks protect the OSS surface
• Public Testing Policy — Maintained test suites and root-test migration policy
• Support — Where to ask for OSS help and what belongs outside the public repo
• Security Policy — Private vulnerability reporting and payment safety invariants
• Code of Conduct — Community expectations for public collaboration

🤝 Contributing

We welcome contributions! Please see our Contributing Guide for details.

Quick contribution checklist:

• Fork the repository
• Create a feature branch: git checkout -b feature/your-feature
• Make your changes with tests
• Run the contributor gate: pnpm run check:contributor
• Submit a pull request

Development setup:

# Clone the repository
git clone https://github.com/EfeDurmaz16/sardis.git
cd sardis

# Install dependencies
pnpm run doctor
uv sync
pnpm install --frozen-lockfile

# Run fast OSS checks
python3 scripts/repo_inventory.py
python3 scripts/oss_surface_check.py
python3 scripts/stale_api_path_check.py
pnpm --filter @sardis/sdk typecheck

# Start local API server
uv run uvicorn --app-dir apps/api server.main:create_app --factory --port 8000

🔗 Links

• Website: sardis.sh
• Documentation: docs.sardis.sh
• Playground: sardis.sh/playground
• GitHub: github.com/EfeDurmaz16/sardis
• Discord: discord.gg/XMA9JwDJ
• PyPI: pypi.org/project/sardis
• npm: npmjs.com/package/@sardis/mcp-server
• Context7 Docs: context7.com/efedurmaz16/sardis

📄 License And Open-Core Boundary

The public repository is licensed under the terms in LICENSE. See OPEN_CORE.md for the product boundary between the open-source authority layer and the hosted Sardis Cloud operations layer.

The intended split is:

• Open source -- mandate semantics, policy evaluation, provider interfaces, simulator providers, SDKs, protocol adapters, examples, and audit schemas.
• Hosted / commercial -- dashboard, RBAC/SSO, approval inbox, managed provider credentials, webhook operations, compliance workflows, audit retention, alerts, and support.