Use case · the best specified
Setting up a tool
Every new tool opens with the same screen: paste an API key, paste another one, grant this, connect that. You end up spraying credentials into an onboarding flow to answer a question the tool could have asked in words, which is simply which accounts it should be looking at.
What happens instead
The tool declares the list of things it needs to watch. Your AI reads that list and proposes the specific accounts and services from what you already run, named rather than credentialed. Your phone shows you the proposal; you approve or reject each entry, and any class the tool flagged as content stays out of what ShareLess hands over unless you switch it on for that entry. ShareLess passes on the approved list with a receipt, and the tool takes it from there.
This is the shape the connection protocol was designed and tested against, which makes it the best specified of the five. Be careful how you read that: a business supplies its list with each request, and no setup request ships inside ShareLess waiting to be run. The example lists in our repository are fixtures the parser is tested against, not something a visitor can trigger.
Names, not keys
Limited pathWhat crosses is a reference: which account, which service, which database. A tool's request declares the field names it must never receive, and ShareLess refuses any proposal or release carrying one of them at any depth, failing the whole submission rather than quietly dropping the offending entry.
That list is the tool's own declaration, not a floor ShareLess imposes, and matching is by field name rather than by inspecting values. A request that declares nothing prohibited gets nothing enforced. Read a manifest before you approve against it.
ShareLess does not obtain the access
Not covered todayThis is the half that does not exist, and it is the half people assume. ShareLess runs no sign-in flow for the services you are pointing the tool at. It holds no token, performs no exchange, and assumes no role. Granting the tool actual access to each provider stays entirely between you and that tool, exactly as it was before. What ShareLess replaced is the part where you had to guess what the tool wanted and paste a credential to find out.
A grant you can revoke
Available nowThe approved list becomes a grant in your ledger. Revoking it marks it revoked and reports that to the tool the next time it pulls the session. Because ShareLess never held the access in the first place, revoking here cannot switch the tool off: whatever you granted the tool directly is ended in that tool's own settings. Two separate places, and we are only one of them.
Who can do this today
Limited pathTools we have onboarded directly. There is no self-serve path for a tool to add ShareLess to its setup flow, no published package to install, and no form that issues a key. Approving still requires the iPhone app on invite-only TestFlight.