Security and privacy

What leaves your agent

Yes-or-no answers, each only as fine as the plan allows. In a scheduling mesh that's free or busy for each candidate time. Scenario plans (dinner, trips, study sessions, and others, in the local preview) can also ask whether a price on a fixed ladder fits your budget, whether you can get to a place within some minutes from an area of about 5 km you choose, whether an option works with your needs, whether you can take a role, or for a ranking of listed options. Nothing else fits: the API refuses extra fields. Your calendar, its event titles, your exact location, and your exact budget stay with your agent.

The alternative, one shared assistant that reads everyone's calendar, can find a time too, but then it holds every event of every person in the group. A mesh never sees a calendar: each agent reads its own person's calendar and sends one free or busy answer per time asked.

In a scenario plan you sign a permission card first. It names the dimensions, the exact window, the price rungs, and where your travel answers start from, and you can switch any dimension off. Your agent can't answer before you sign, and the server checks every answer against the signed card.

Who sees what

• Other people in the mesh see the proposed time, how many times each person has answered, and each person's calendar report. In a plan of 3 or more people they see how many approved, not who, until the plan is set. They never see anyone's answers. In a plan that goes ahead when at least 80% say yes, once it's set they see who's coming, and so who isn't.
• You see everything your own agent told the mesh, through mesh_disclosures or GET /meshes/:id/disclosures.
• The service, and Scope as its operator, stores every answer from every person, encrypted, until the plan ends, and reads them while the plan is open to find what works.

Questions reviewers ask

Can Scope link my answers across plans?

Not after a plan ends. Answers are stored under an id that exists only inside one plan, and they're deleted when the plan is set, falls through, is cancelled, or expires, so no history of your answers is left to link. What Scope can still see: while a plan is open, the server reads its answers. In a group chat, every plan you take part in is tied to the same member, so Scope can see which plans you were in, when, and how many questions you answered. Across standalone meshes, your name, your agent's name, or a reused key could link them. Travel checks are kept for 30 days in a form only the server's key can test.

Are answers encrypted at rest?

Yes, but not end to end. Each plan's answers, and any area someone shares, are encrypted with that plan's own key (AES-256-GCM), and that key is itself encrypted under a key only the running server holds. A copy of the database on its own doesn't show them. While a plan is open, the server decrypts answers to compare them, so Scope, which runs it, could read them then. Tokens are stored only as SHA-256 hashes, and server-held signing keys are sealed with AES-256-GCM.

Who controls the signing keys?

By default, the server. It makes your key pair and keeps the private key sealed under a key Scope holds, so Scope could sign as you. An agent can bring its own instead: send publicKey when it creates or joins a mesh, and the server holds nothing and the agent signs every approval itself. See the Mesh API.

Can my agent check what it approved without trusting Scope?

Yes. Each approval signs a hash of the whole plan: the contract, every participant and their public key, and the exact proposal. Before approving, your agent can read that exact plan from GET /meshes/:id/receipt and recompute its hash; with its own key, it signs that hash and nothing else. Afterwards the same endpoint returns the record, and verifyReceipt checks it with nothing but node:crypto. Pass the keys you trust, such as your own, to check who signed as well as that the record is consistent. With a server-held key, the check shows the server signed for you; it can't show that you agreed.

Why aren't answers deleted when a plan ends?

They are now. When a plan is set, falls through, is cancelled, or expires, its answers, any shared areas, and that plan's key are deleted right away. The signed record doesn't need the answers: it holds salted hashes of them, so receipts still check out. The whole plan is deleted 30 days after it expires, and a plan that's set stays until 30 days after its time. To prove your answers later, save your disclosures before the plan ends.

Limits

Mesh doesn't limit how many questions anyone is asked. It limits how fine each answer can be, and it only asks inside what each person consented to, so what anyone can learn is capped by that consent however many questions or plans are used. These are the things that still leak, and what Mesh does about each. The threat model has the full list, the attacks it was tested against, and the measurements behind these numbers, measured on the local service on November 5, 2026.

• Answers still say something. Busy at 6 PM every night says something about your week, and a proposed time tells everyone that all of you were free then.
• Time answers map what you allowed. Free or busy is only ever on a 30-minute grid, and only inside the window your card names. Asking again adds nothing. Every plan in a group chat has its own card, each naming its own window, so the bound is what your agent signs: measured, a member offering plan after plan, each card naming a different day, pinned down all 112 half-hours of a week from an agent that signed every card. An agent that signs only the windows you mean to share reveals only those. With availability off in a group, a card that includes time is refused, and so is any time answer.
• Budgets reveal a bucket. Budget questions name only amounts on a fixed ladder ($10, $20, $50, $100, and so on up to $5,000), rounded up. A group has one currency, fixed when it's created, so the same ladder can't be asked again in another currency. Twenty plans of binary search on a $137 budget prove only that it's between $100 and $200, and no number of plans learns more than which of 10 buckets it's in (3.32 bits). Without the ladder, they find $137.
• Travel reveals an area. Travel answers come from the center of an area of about 5 km that you choose, committed in your signed card, and the server refuses an answer that contradicts an earlier one from the same area. Measured, answers from your exact spot would pin you to about 1 km² in 10 questions. From the area they stop at one 25 km² block (5.17 bits), and 1,000 questions recover nothing finer. The server holds that area, encrypted, to check answers, never shows it to anyone, and deletes it when the plan ends.
• Small groups reveal more. With two people, the outcome tells each of you about the other: in the measured worst case, 5.46 of your 16 bits. A two-person plan says so in a warning before anyone answers. From 3 people up, approvals show as a count until the plan is set, and two of four people pooling everything they see learn 0 bits about which of the others declined (1 bit with names shown). Everyone but you, working together, can still tell what you chose. A plan that goes ahead when at least 80% say yes is set without everyone, and from then on the group sees who's coming, and so who isn't. The card each person signs says so first. Each person can decline once, and a plan makes at most 3 proposals.
• Agents and people can lie. An agent can say busy when its person is free, or approve without asking. The mesh never sees a calendar, so it can't check. What it adds is attribution: each answer is a salted commitment inside the person's signed approval, so they can't later claim they answered otherwise. The approve tool is marked so assistant apps ask the person first.
• You trust whoever runs the service. Answers, and each person's 5 km travel area, are stored encrypted and deleted when the plan ends, but while a plan is open the server reads them, and Scope runs the server. Tokens are stored only as SHA-256 hashes. Unless an agent brings its own key, the server holds each participant's signing key, sealed with AES-256-GCM under a key Scope also holds, so Scope could sign as them. A mesh closes 7 days after it's created and is deleted 30 days after that.
• The outcome is a disclosure. A proposed place says everyone could reach it, afford it, and eat there. A role names who said yes to driving or hosting.
• Taking it back doesn't erase what the outcome told. Leaving before the time is set closes the plan for everyone. After it's set, anyone can revoke their approval, which cancels the plan for everyone and adds a signed revocation to the receipt. Either way the answers are deleted when the plan ends, but what the proposal already told the others stays told.
• Timing and metadata. Event timestamps can hint at who just approved. Names, agent names, and how many questions each person answered are visible to everyone in the plan.

Signed approvals and receipts

An approval is an Ed25519 signature over a hash of the whole plan (the contract, each participant and their public key, and the exact proposal) and the signer's own answers commitment. A decline brings a new proposal version, and approvals of the old one stop counting. When everyone approves the same version, the mesh commits. Each agent then signs its calendar report, and anyone who revokes signs that too.

GET /meshes/:id/receipt returns all of it, and verifyReceipt checks it with nothing but node:crypto: the hash, every signature against the key the contract names, and that the commitment rests on one approval from each person. Answer commitments are salted hashes, so the receipt shows how many questions each person answered and nothing about the answers. See the Mesh API for the exact formats.

Approval belongs to the person, not the agent. The mesh can check that an approval is signed with the right key. It can't check that the agent asked its person first.

Abuse limits

• These limit spam, not questions: 60 plans a day per group, one plan going at a time per organizer in a group, 30 creates, joins, or previews a minute per IP address, and 240 requests a minute per participant token.
• Request bodies over 16 KB are refused, and a plan holds at most 336 times, 50 options, and 20 roles.
• A standalone mesh holds 2 to 8 people, and at most 3 times that many can ever join it.
• Rate limits are counted per server instance. A shared limiter is needed before the service is deployed.

Not built yet

• Accounts and identity beyond a per-mesh token and key.
• Booking or paying for anything. A plan can name a place or a gift, and Mesh never books or buys it.
• Private computation, where the service finds the overlap without seeing anyone's answers. Nothing like that is built.

The home page demo

The demo runs the real state machine on the server, in memory, for one request at a time, and saves nothing. Its approvals and calendar reports are signed the same way, with throwaway keys made for each run. The four sample people answer from sample calendars that never reach your browser. Automated tests check that no event title or busy time from those calendars appears in what the page receives.