惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Apple Machine Learning Research
Apple Machine Learning Research
博客园 - 三生石上(FineUI控件)
雷峰网
雷峰网
WordPress大学
WordPress大学
S
SegmentFault 最新的问题
博客园 - 叶小钗
The Cloudflare Blog
T
Tailwind CSS Blog
Hugging Face - Blog
Hugging Face - Blog
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
月光博客
月光博客
小众软件
小众软件
罗磊的独立博客
酷 壳 – CoolShell
酷 壳 – CoolShell
大猫的无限游戏
大猫的无限游戏
阮一峰的网络日志
阮一峰的网络日志
V
V2EX
美团技术团队
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
博客园 - 聂微东
量子位
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
宝玉的分享
宝玉的分享

DEV Community

Authentication Security Deep Dive: From Brute Force to Salted Hashing (With Java Examples) Why AI Systems Don’t Fail — They Drift Spilling beans for how i learn for exam😁"Reinforcement Learning Cheat Sheet" I Replaced Chrome with Safari for AI Browser Automation. Here's What Broke (and What Finally Worked) How Python Borrows Other People's Work The $40 Architecture: Processing 1 Billion API Requests with 99.99% Uptime Vibe Coding: A Workflow Guide (From Zero to SaaS) Most webhook security guides protect the wrong side. The scary part is delivery. Headless CMS for TanStack Start: Build a Blog with Cosmic EU Age Verification App "Hacked in 2 Minutes" — What Actually Happened Comfy Cloud’s delete function does not actually remove files Running AI Models on GPU Cloud Servers: A Beginner Guide Event-driven media intelligence with AWS Step Functions and Bedrock I scored 500 AI prompts across 8 quality dimensions — here's what broke How to Call Google Gemini API from Next.js (Free Tier, No Backend Needed) The Portal Protocol: Reclaiming Human Connection in the Age of AI How to Fix Your Team's Scattered Knowledge Problem With a Self-Hosted Forum Intro to tc Cloud Functors: A Graph-First Mental Model for the Modern Cloud Designing Multi-Tenant Backends With Both Ownership and Team Access I Built a Neumorphic CSS Library with 77+ Components — Here's What I Learned PostgreSQL Performance Optimization: Why Connection Pooling Is Critical at Scale Cómo construí un SaaS multi-rubro para gestionar expensas en Argentina con FastAPI + Vue 3 🚀 I Built an Ethical Hacking Scanner Tool – Open Source Project I Replaced /usage and /context in Claude Code With a Single Statusline A Pythonic Way to Handle Emails (IMAP/SMTP) with Auto-Discovery and AI-Ready Design I Collected 8.9 Million Polymarket Price Points — Here's What I Found About How Markets Really Move EcoTrack AI — Carbon Footprint Tracker & Dashboard Everyone's Using AI. No One Agrees How. 5 self-hosted ebook managers worth trying in 2026 Building Your First AI Agent with LangChain: From Chatbot to Autonomous Assistant
Session-Level Spending Limits Are Not Governance. Your Ag...
Kavin Kim · 2026-06-27 · via DEV Community

4 days until MiCA enforcement. AWS Bedrock AgentCore shipped session-level spending limits. Coinbase x402 shipped per-request payment authorization. Both solve the wrong problem.

A $0.50 API call and a $5,000 service procurement should not pass through the same governance gate. One needs instant approval. The other needs multi-step verification, budget owner sign-off, and an audit record that satisfies MiCA Article 67.

Session-level limits treat all spending as equal. That is not governance. That is a cap.

The Flat Limit Problem

Every agent payment platform launched in 2026 ships the same primitive: a spending ceiling per session or per time window. Ramp documented the pattern. Finout documented why it fails. The arxiv "Dynamic Tiered AgentRunner Framework" paper formalized the gap: insufficient governability means high-risk write operations proceed without independent review.

Here is what flat limits produce in production:

# FLAT LIMIT: Every payment gets the same treatment
# AWS Bedrock AgentCore default pattern

agent_config = {
    "session_spending_limit": "$100",
    "time_window": "24h",
    "approval_required": False  # No escalation path
}

# What happens in practice:
transactions_today = [
    {"amount": 0.02, "type": "embedding_api_call"},      # Routine
    {"amount": 0.50, "type": "search_api_query"},         # Routine
    {"amount": 4.99, "type": "data_subscription"},        # Low risk
    {"amount": 47.00, "type": "cloud_compute_burst"},     # Medium risk
    {"amount": 89.00, "type": "third_party_agent_hire"},  # HIGH RISK
]

# All pass the $100 limit. No differentiation.
# The $89 third-party agent hire gets the same scrutiny as a $0.02 embedding call.
# No budget owner notified. No audit trail distinguishing routine from exceptional.
# MiCA auditor asks: "Who approved the $89 agent-to-agent payment?"
# Answer: "Nobody. It was under the session limit."
# MiCA auditor: "That is not a compliant answer."

total = sum(t["amount"] for t in transactions_today)
print(f"Daily spend: ${total:.2f}")  # $141.51 - over limit but individual txns pass
# Even worse: 50 agents x $100/day = $5,000/day with zero oversight

What Autonomy Tiering Looks Like

Tiered governance assigns different approval workflows based on transaction characteristics, not just amount. Amount is one signal. Category, recipient trust level, frequency pattern, and regulatory jurisdiction all factor in:

// TIERED GOVERNANCE: Different rules for different risk profiles
import { RosudPay, GovernanceTier } from 'rosud-pay';

const governance = RosudPay.configure({
  agentId: 'procurement-agent-prod',
  network: 'base-mainnet',

  tiers: [
    {
      name: 'autonomous',
      // Agent decides alone. No human. Instant execution.
      conditions: {
        maxAmount: 1.00,
        categories: ['api_calls', 'embeddings', 'search'],
        recipientTrust: 'verified',     // Only pre-approved vendors
        frequency: { max: 1000, per: '1h' }
      },
      approval: 'none',
      audit: 'batch_daily',             // Aggregated daily report
      micaCompliance: 'simplified'      // Lightweight record
    },
    {
      name: 'supervised',
      // Agent decides, human gets notified. 30s window to veto.
      conditions: {
        maxAmount: 50.00,
        categories: ['compute', 'data_access', 'saas_tools'],
        recipientTrust: 'known',        // Previously transacted
        frequency: { max: 20, per: '1h' }
      },
      approval: 'notify_with_veto',
      vetoWindow: '30s',
      audit: 'per_transaction',         // Individual record
      micaCompliance: 'standard'        // Full lifecycle record
    },
    {
      name: 'collaborative',
      // Agent proposes, human approves. Cannot execute alone.
      conditions: {
        maxAmount: 5000.00,
        categories: ['agent_hire', 'service_procurement', 'subscription'],
        recipientTrust: 'any',
        frequency: { max: 5, per: '24h' }
      },
      approval: 'explicit_human',
      timeout: '4h',                    // Auto-reject if no response
      audit: 'per_transaction_enhanced', // Full chain with justification
      micaCompliance: 'enhanced'        // Regulator-queryable record
    },
    {
      name: 'prohibited',
      // Agent cannot attempt. Hard block.
      conditions: {
        categories: ['gambling', 'unverified_agents', 'sanctioned_jurisdictions'],
        recipientTrust: 'unknown'
      },
      approval: 'blocked',
      audit: 'attempt_logged',          // Even attempts are recorded
      alert: 'immediate_to_owner'
    }
  ]
});

// Runtime: the governance layer classifies each transaction automatically
const payment = await governance.authorize({
  amount: 89.00,
  category: 'agent_hire',
  recipient: 'analysis-agent-beta.example',
  recipientTrust: 'known',
  justification: 'EURC liquidity analysis for MiCA compliance report'
});

// Result: tier = 'collaborative', requires explicit human approval
// Payment queued. Owner notified. Audit record created with justification.
// If approved: executes with full provenance chain.
// If timeout: auto-rejected, agent notified, alternative path suggested.
console.log(payment.tier);       // 'collaborative'
console.log(payment.status);     // 'awaiting_approval'
console.log(payment.auditId);    // 'aud-2026-06-27-001'

Why MiCA Requires Tiering (Not Just Limits)

MiCA Article 67 requires "proportionate" risk management. Proportionality means: the governance applied to a transaction must match its risk profile. A flat $100 limit applied uniformly to all transaction types is explicitly non-proportionate.

The regulatory logic:

# MiCA proportionality test for agent payment governance

def mica_proportionality_check(governance_config):
    """
    MiCA Article 67 requires risk management that is
    'proportionate to the nature, scale, and complexity'
    of the crypto-asset service.
    """

    # FAIL: Flat limit treats all transactions identically
    if governance_config.get("type") == "flat_limit":
        return {
            "compliant": False,
            "reason": "Uniform limit does not differentiate by nature/scale/complexity",
            "regulatory_risk": "NCA may determine insufficient risk controls",
            "remediation": "Implement tiered governance with per-category rules"
        }

    # PASS: Tiered governance differentiates by risk profile
    if governance_config.get("type") == "tiered":
        tiers = governance_config.get("tiers", [])
        checks = {
            "nature_differentiated": len(set(t.get("categories") for t in tiers)) > 1,
            "scale_differentiated": len(set(t.get("maxAmount") for t in tiers)) > 1,
            "complexity_differentiated": any(t.get("approval") == "explicit_human" for t in tiers),
            "audit_proportionate": any(t.get("audit") == "per_transaction_enhanced" for t in tiers),
            "prohibited_categories_defined": any(t.get("approval") == "blocked" for t in tiers)
        }

        all_pass = all(checks.values())
        return {
            "compliant": all_pass,
            "checks": checks,
            "regulatory_confidence": "high" if all_pass else "medium"
        }

# The difference on July 1:
flat_result = mica_proportionality_check({"type": "flat_limit", "limit": 100})
print(f"Flat limit: compliant={flat_result['compliant']}")  # False

tiered_result = mica_proportionality_check({
    "type": "tiered",
    "tiers": [
        {"categories": ["api"], "maxAmount": 1, "approval": "none", "audit": "batch"},
        {"categories": ["compute"], "maxAmount": 50, "approval": "notify", "audit": "per_tx"},
        {"categories": ["procurement"], "maxAmount": 5000, "approval": "explicit_human", "audit": "per_transaction_enhanced"},
        {"categories": ["prohibited"], "maxAmount": 0, "approval": "blocked", "audit": "attempt_logged"}
    ]
})
print(f"Tiered: compliant={tiered_result['compliant']}")  # True

The Implementation Gap

Five categories of spend controls exist in 2026: one-time tokens, time-bounded JWTs, programmable on-chain allowances, cryptographic mandates, and real-time approval flows. Each solves one dimension. None composes them into a tiered governance framework that satisfies both operational efficiency and regulatory proportionality.

rosud-pay implements autonomy tiering as the default governance model. Every transaction is classified by amount, category, recipient trust, and frequency pattern. Each tier applies different approval workflows, different audit depths, and different compliance record formats. The agent that processes 1,000 micro-API calls per hour and the agent that procures a $5,000 service once per week operate under the same identity but different governance rules.

The Bottom Line

Session-level limits are training wheels. They prevent catastrophic overspend but provide zero governance signal. After July 1, MiCA requires proportionate risk management. "Everything under $100 is auto-approved" is not proportionate. It is negligent.

Tiered autonomy is the minimum viable governance for agent payments in a regulated environment. Build it now, or explain to your NCA auditor why a $0.02 embedding call and an $89 agent hire received identical oversight.


Build tiered agent payment governance: rosud.com/docs