accesscontrol

Article 7
This article explains the technical implementation of SafeClaw's multi-user system — how user isolation works, how access control is enforced, and how the three Binance account types are routed.

━━━ THE CORE CHALLENGE ━━━

A single-user AI agent is relatively simple to secure. A public multi-user agent handling real financial API keys is a fundamentally different problem.

The requirements:
1. User A's API key must be invisible to User B
2. User A's trade history must be invisible to User B
3. User A's DCA plan must not affect User B's
4. A compromised session for User A must not expose User B
5. The bot must route each user's API calls to the correct Binance environment

SafeClaw solves all five.

━━━ SESSION ISOLATION ARCHITECTURE ━━━

OpenClaw's session system is configured with:
dmScope: "per-channel-peer"

This means: every unique Telegram user ID gets its own isolated session context.

Technically, what this means:
• Each user's messages are processed in a separate session namespace
• Session data (stored in sessions.json) is keyed by Telegram user ID
• No user's session can read from another user's session
• The AI agent's context for each user contains only that user's data

Session data stored per user:
• binance_account_type (live/demo/testnet)
• binance_live_key, binance_live_secret
• binance_demo_key, binance_demo_secret
• binance_testnet_key, binance_testnet_secret
• binance_square_key
• currency, payment_methods, risk_profile
• dca_asset, dca_amount, dca_interval, dca_history
• simulation_history, evaluation_scores

None of this data is accessible to other users.

━━━ THE THREE-ACCOUNT ACCESS CONTROL SYSTEM ━━━

SafeClaw supports three distinct Binance account types per user. The api-router skill handles routing:

REAL ACCOUNT (Production)
Command: /updatekey [KEY] [SECRET]
Validation endpoint: https://api.binance.com/api/v3/account
Trading endpoint: https://api.binance.com
Futures endpoint: https://fapi.binance.com
Use case: Live DCA, real Earn monitoring
Security: Withdrawal permission = instant reject
IP restriction: Users told to restrict to server IP

DEMO ACCOUNT (Practice)
Command: /updatekey-demo [KEY] [SECRET]
Validation endpoint: https://demo-api.binance.com/api/v3/account
Trading endpoint: https://demo-api.binance.com
Futures endpoint: https://demo-fapi.binance.com
Use case: Academy simulation, strategy testing
Balance: 5,000 USDT provided by Binance
Security: No real funds, no withdrawal risk

TESTNET (Development)
Command: /updatekey-testnet [KEY] [SECRET]
Validation endpoint: https://testnet.binance.vision/api/v3/account
Trading endpoint: https://testnet.binance.vision
Use case: Developers building on Binance, API testing
Balance: Testnet funds from testnet.binance.vision

━━━ API KEY VALIDATION FLOW ━━━

Every key submitted goes through this exact process:

1. Format validation
Key length: must be 64 characters
Character set: alphanumeric only
If invalid: "Invalid key format. Please check and retry."

2. Live API call
GET {correct_endpoint}/api/v3/account
With HMAC SHA256 signed timestamp
Timeout: 10 seconds

3. Permission inspection
Parse .permissions array from response
If "WITHDRAWALS" present → reject
If "TRANSFER" present → reject
If "SPOT" absent → warn user (may not be able to trade)
If canTrade = false → warn user

4. Storage
On success: stored in user's session memory
Account type flag set: "live" / "demo" / "testnet"
User notified with account label

5. Security prompt
"✅ [Account type] connected."
"⚠️ Please DELETE your /updatekey message from chat now."

━━━ ROUTING LOGIC ━━━

Every skill that executes a Binance API call reads from the api-router skill:

api-router reads: binance_account_type from session
Returns: BASE_URL, FUTURES_URL, USER_KEY, USER_SECRET, ACCOUNT_LABEL

Skills that use api-router:
• smartdca (every DCA execution)
• safeclaw-academy (every simulation)
• yield-monitor (every Earn query)
• profile (balance display)
• guardianclaw (when executing approved trades)

Skills that do NOT need api-router (public APIs):
• p2p-safefinder (P2P API is public)
• briefing (price data is public)
• square-content-engine (news/trends are public)

━━━ WHAT HAPPENS WHEN NO KEY IS SET ━━━

If a user tries to run /dca run or /simulate without a configured key:

"⚠️ No Binance account connected.

To use this feature:
• /updatekey — Real Binance account
• /updatekey-demo — Practice account (RECOMMENDED)
• /updatekey-testnet — Developer testnet

P2P search and market briefings work without an API key."

The bot never falls back to server-level credentials. If no user key is configured, the feature is unavailable for that user.

━━━ CONCURRENT USER HANDLING ━━━

OpenClaw's configuration:
agents.defaults.maxConcurrent: 4
agents.defaults.subagents.maxConcurrent: 8

This means:
• Up to 4 main agent executions run in parallel
• Up to 8 sub-agent operations per main agent
• Additional requests are queued — no dropped messages

On t3.small (2 vCPU, 2GB RAM), this comfortably handles dozens of concurrent users. The main bottleneck is OpenRouter API rate limits, not server resources.

━━━ FUTURE EXPANSION ━━━

Multi-instance scaling:
• Redis session store enables multiple OpenClaw instances to share state
• Load balancer distributes Telegram webhook traffic
• Each instance handles a subset of users with identical capabilities

Per-user model selection:
• Premium users could route to Claude Sonnet for higher accuracy
• Free tier routes to free fallback models
• Model selection stored in user session

User tiers:
• Free: P2P, Briefing, Learn
• Standard: + DCA, Guard, Academy
• Premium: + Yield, Content Engine, Priority routing
Quick Links:
Article 1 Article 2 Article 3 Article 4 Article 5 Article 6 Article 8

Source: https://github.com/bnbnepalbinanceangel/SafeClaw

#AIBinance #SafeClaw #MultiUser #AccessControl #OpenClaw