Threat model
What Scope Mesh protects, against whom, what it doesn't, and how much a plan reveals, measured. It covers the local service: nothing is deployed yet.
The numbers come from the Scope Mesh repository's leakage measurement (November 5, 2026), and its adversarial tests assert them. Each attack runs through the real API and MCP tools. The limits live in one file, and the security notes summarize them.
What's protected
- Each person's answers. Every question is yes or no (“free Thu 6–7 PM?”, “can you spend up to $50 per person?”). Only the person who gave an answer sees it. Others get the outcome and how far each person has got.
- Who approved and who declined, in plans of 3 or more, until everyone has approved.
- How much anyone can be asked, per plan, per pair of people, and per person per day.
- Agreements. Every approval, calendar report, and revocation is an Ed25519 signature over the exact contract, and anyone can check it offline.
Who the adversary is
In scope: a hostile participant's agent, as organizer or joiner, using every endpoint and tool, answering however it likes (including lying), declining, withdrawing, leaving, rejoining, and racing requests. Also groups of participants who pool what they see, and anyone holding a receipt who tries to alter or forge it.
Out of scope, and so not protected: the server operator, a compromised agent acting for its own person, and side channels outside the API, such as network timing.
The limits
| Limit | Default | What it bounds |
|---|---|---|
| Questions per plan, per person | 16 | One plan's disclosure to 16 bits. Stated in the contract before anyone joins. |
| Budget amounts | $10, 20, 50, 100, 200, 500, 1,000, 2,000, 5,000 per person, rounded up | What any number of plans learns about a budget to log2(10) = 3.32 bits. |
| Plans per pair (groups) | 3 per 24 hours | How often one member can probe another. |
| Questions per member (groups) | 48 per 24 hours, all plans | What anyone learns about one person per day, whoever asks, through rejoins. |
| Plans per group | 10 per 24 hours | Churn by many accounts. |
| Proposals per plan | 3 | How far declines can walk through someone's free times. |
| Counts only | Plans of 3 or more, until commitment | Who approved, and so who declined. |
Rounding a budget up never turns a “no” into a “yes”: whoever can afford the rung can afford the real price. The cost is that someone whose limit is $45 says no to a $35 dinner asked as “up to $50.” Two-person plans don't hide names, because the outcome alone gives the other person's choices away. The API warns both people instead.
What one plan's outcome reveals
No rule can hide the outcome, since it's the point of the plan. This table is exact: 16 candidate times, each person free at each with probability 1/2, honest answers. A coalition is the participants who pool what they know. Each person's answers are 16 bits at most.
| People | Coalition | Proposals seen | Bits about one person outside it | From the outcome alone |
|---|---|---|---|---|
| 2 people | 1 | 1 | 1.98 | 1.23 |
| 2 people | 1 | 3 | 5.46 | 3.40 |
| 3 people | 1 | 1 | 1.10 | 0.97 |
| 3 people | 1 | 3 | 2.26 | 2.00 |
| 4 people | 1 | 3 | 1.08 | 1.03 |
| 4 people | 2 | 3 | 1.22 | 1.03 |
| 4 people | 3 | 3 | 1.96 | 1.03 |
| 8 people | 1 | 3 | 0.06 | 0.06 |
| 8 people | 4 | 3 | 0.07 | 0.06 |
In a two-person plan where the other person declines to see a second and third proposal, they learn 5.46 of your 16 bits. In a group of 4, two colluders learn 1.22 bits about each of the other two, 0.19 more than the outcome tells anyone. Bigger groups reveal less per person, because a proposal needs everyone free.
Before and after the limits
“Before” turns off exact-amount rounding, the 16-question cap, the daily limits, and hidden names.
| Attack | Before | After |
|---|---|---|
| Binary-search a $137 budget, 20 plans | $137 exactly (13.29 bits) | $100 to $200 (6.64 bits; at most 3.32 on average) |
| Map a week of 112 half-hour slots in one day | 41.7 slots pinned down, in 10 plans | 10.7 slots, in 3 plans, stopped by the 48-question budget |
| 2 of 4 colluders learn who declined | 1 bit (they can tell) | 0 bits (identical views) |
Attacks and results
| Attack | Result |
|---|---|
| Binary-search a $137 budget over 20 plans | The victim is asked only ladder amounts. The attacker proves $100 ≤ budget < $200. With the ladder off, they learn exactly $137. |
| Probe a calendar plan after plan, leaving and rejoining to reset limits | 3 plans (the pair limit), then the victim's 48-question daily budget stops it. |
| Ask more: a 24-time window, made-up question ids, answers past the daily budget | 16 questions at most, unknown ids refused, and answers past the budget refused. |
| 2 of 4 collude to learn who declined | Everything they can read is byte-identical whichever of the other two declined. With names shown, it differs. |
| Read approvals before commitment | Others' approvals are hidden, the log says “Someone approved (k of n)”, and the receipt shows only your own signature. |
| Read another participant's answers through every endpoint and MCP tool | Worlds that differ only in one person's answers look identical to everyone else. |
| Approve a stale version, or reuse a version 1 signature on version 2 | Refused, and the old signature doesn't verify for the new contract. |
| Replay a signature in another mesh with an identical contract | Refused: the signed message names the mesh and the participant. |
| Sign as someone else | Refused. A token only ever approves as itself. |
| Tamper with a receipt: move the time, swap, fabricate, or drop signatures | Verification fails. A fully re-keyed forgery is self-consistent, and fails once checked against keys you trust. |
| Race approve against withdraw, and revoke against a calendar report | Either order can happen, every final record verifies, and nothing is recorded after a revocation. |
| Claim a different answer after approving | The changed answer doesn't match the answers commitment in the signed approval. |
What Mesh doesn't protect
- The server operator. Answers are stored in plain text next to their salts, and the operator can read them all. Server-held signing keys are sealed with a key the operator also holds, so the operator could sign as anyone who uses one. Joining with your own key rules out forged approvals, reports, and revocations, but not reading answers. The sealing key can't be rotated yet.
- A participant who lies. Mesh can't know anyone's real calendar or budget. A liar can block a plan by saying busy everywhere, or learn more by saying free everywhere (the numbers above assume an attacker does). What Mesh adds is attribution: each answer is a salted commitment inside the person's signed approval, so they can't later claim they answered otherwise.
- Everyone but one. With one honest person left, any decline that isn't the coalition's is theirs. Counts-only views protect against coalitions of up to n − 2.
- Two-person plans. The outcome tells each person the other's answers at every time they both checked. The API warns, and can't prevent it.
- Timing. Events carry timestamps. Someone who knows when a person is usually awake can guess who just approved, and the log names who finished answering.
- Standalone meshes. The pair and daily limits apply in groups only. A standalone mesh relies on the per-plan limit, per-IP request limits, and each person agreeing to join.
- Rejoining as the victim. A member who leaves and rejoins gets a fresh daily budget. Only they can do that.
- Cancelling. Anyone can revoke a committed plan, which calls it off for everyone. That's the unanimous rule, and it means one person can spoil a group's plans, once each.
- Per-instance limits. Per-minute request limits are counted in memory on each server instance. The daily check at answer time isn't in the same transaction as the answer, so two answer batches at once can both pass it. Plan creation, the main check, runs under the group lock.
- Metadata. Names, agent names, how many questions each person answered, and the candidate times are visible to everyone in the plan.
- Receipts prove consistency, not identity. A receipt carries its own keys. Check signers against keys you trust.