Two Binance accounts selected the same permissions and exposed the same measured trading surface. Binance permission self-report gave different answers.
KEYRING is an AI permission auditor for Binance Agent OS. It measures what a connected AI agent can reach, stops every test before an order can execute, and keeps a source record behind every number on this page. Nothing here is typed in by hand.
Each row compares one source across Account A and Account B: the permission selected, Binance's self-report, the tools exposed to the agent, and controlled tests. The first, third, and fourth rows stayed the same. Only Binance's self-report changed.
The permission approved on the Binance consent screen, read back from the connection itself.
Reported by the connection · Granted MCP scopesBinance's own description of the credential — the surface someone would query to audit a live session.
Reported by Binance · wallet.getApiKeyPermissionThe tools the live session actually exposed to the agent, counting the ones that can write.
Reported by the session · tools/listTrading-shaped requests built to be rejected at Binance's own checks, before anything could execute.
Measured by KEYRING · controlled non-executing requests| The way we asked | Account A | Account B | Across accounts |
|---|---|---|---|
1 What you agreed toGranted MCP scopes | Spot & Margin trading · Futures trading | Spot & Margin trading · Futures trading | Same answer |
2 Binance permission self-reportwallet.getApiKeyPermission | Spot ✕ · Futures ✕ | Spot ✓ · Futures ✓ | Different answer |
3 What the agent was handedtools/list | 71 tools · 11 trading writes | 71 tools · 11 trading writes +8 more | Same answer |
4 What KEYRING measuredcontrolled non-executing requests | Spot: validation reached ✓ · USDⓈ-M: validation reached ✓ · COIN-M: validation reached ✓ | Spot: validation reached ✓ · USDⓈ-M: validation reached ✓ · COIN-M: validation reached ✓ | Same answer |
Same permission set. Same measured trading surface. Different self-report. Account A reported spot and futures trading disabled. Account B reported spot and futures trading enabled. Both trade-grant surfaces exposed the same 71 tools and 11 writes, and KEYRING independently confirmed the same 3 trading families on both.
The endpoint used to describe the credential returned different trading flags, while the connected surfaces were measured directly. This is an observability gap, not a broken control: enforcement was never shown to be weak.
Binance discovers tool schemas and exchange filters at runtime, so the test values cannot be written in advance — a model reads the live schema and proposes one. It then has to get past a deterministic gate it does not control, and it never owns the published answer.
Capture the tool schema the session exposes and the target symbol's live exchange filters.
Deterministic codeThe model reads that schema and proposes a tool, arguments, the filter it expects to violate, and why it should stop there.
ModelThe proposal is rejected unless it violates a named live filter and stays under the notional minimum. The model cannot skip this.
Deterministic codeA read check, one budgeted request, and a complete account snapshot before and after it.
Deterministic codeThe classifier owns the published result. Where the model disagreed, both readings are kept.
Deterministic codeThe endpoint used to describe the credential returned different trading flags, while the connected surfaces were measured directly. This is an observability gap, not a broken control: enforcement was never shown to be weak.
2 of 4 observed account, client and mode combinations showed a confirmation prompt before a trading request; the rest did not. Because the prompt belongs to the client, the answer is kept per row rather than collapsed into one.
Manually recorded revocation trial: known-permitted reads were followed by a denied read; interval is measured from the last permitted response to the first denied response, not from the web UI click
One card per trading area. Open any card to see the request that was sent, the response Binance returned, the before/after state check, and the numbered records behind all of it.
A deliberately safe request reached Binance's own checks and stopped before an order could execute.
A deliberately safe request reached Binance's own checks and stopped before an order could execute.
A deliberately safe request reached Binance's own checks and stopped before an order could execute.
No write action for this area appeared in the connected tool list.
No write action for this area appeared in the connected tool list.
No write action for this area appeared in the connected tool list.
The example strategy declares what it needs. The connection measured more than that. The two are kept apart on purpose — extra access is only counted where it was actually measured.
Declared in a checksummed strategy file.
Measured as extra product access, separate from the strategy's needs.
Each number answers a different question, so they are never merged into one. The capability checks were non-executing; a separate, explicitly approved buy and sell is reported on its own.
Whether a confirmation prompt appears before a trading request is a property of the client, not of the account — so it is never collapsed into a single answer. Each row keeps its own observation.
| Account · client · mode | Before a trading request | Reachable capital | Movable without approval | How it was captured | Evidence |
|---|---|---|---|---|---|
| Account ADirect gateway · not applicable | No prompt observed | — | — | ||
| Account AClaude Code · default mode | No prompt observed | 0 USDT | 0 USDT | ||
| Account AClaude Code · manual mode | Prompt shown | 0 USDT | 0 USDT | ||
| Account BCodex CLI · default mode | Prompt shown | 5.59 USDT | 0 USDT |
Within each active evidence file, every record links to the one before it; an edit breaks that file's verification. Search all 329 records below, or click any evidence chip on the page to jump into one.
| Record | Type | Operation | Result | Code | How it was captured |
|---|
These are observations about what the connected surfaces said or did. None of them is presented as an exploit, and none of them showed enforcement to be weak.
No — the grant has to be disconnected and authorized again
Direct gateway / not applicable: no confirmation (OBSERVED · harness); Claude Code / default: no confirmation (OBSERVED · operator); Claude Code / manual: confirmation shown (OBSERVED · operator); Codex CLI / default: confirmation shown (OBSERVED · operator)
The capability checks were designed to stop before an order could execute, and account state was checked before and after each one. A separate, explicitly approved buy/sell measurement is shown separately. This page is read-only. KEYRING performs the audit. An AI model can propose bounded test inputs, but deterministic KEYRING code controls every request and final classification.
KEYRING measured 3 trading areas and found 11 exposed trading write tools. Each capability check stopped before execution, and the account state matched before and after those checks.