Use case · the flagship
The first week of a job is a paperwork tax. Payroll needs a stack of details, HR needs a different stack, and you end up emailing documents that contain far more than anyone asked for. This is the shape we are building to replace that, and the honest account of how far it goes.
You accept an offer on a Thursday. Instead of a welcome packet with eleven attachments, the employer sends one link.
You open it. It shows you who is asking and what they say they need, and asks you to sign in. Nothing has been shared yet, and the employer cannot see who claimed the link until you approve something.
You hand the link to the AI you already use. It reads the exact list the employer declared, works out which concrete entries fit from what it can see on your behalf, and proposes them. Those entries come from your AI's own discovery, not from your ShareLess vault: nothing wires the vault into a connection proposal today. The employer never receives your passwords or secrets, because its request names the fields it must never be given and ShareLess refuses those at any depth, both when your AI submits an item and again on the assembled release.
Your phone buzzes. One review: every item your AI proposed, each one switched on, with anything counted as content switched off unless you turn it on yourself. You switch off the two entries you would rather not share. You press and hold, confirm with Face ID, and that is the approval.
The employer's system pulls the result: the items you left on, a receipt id, and a grant id. Your ShareLess ledger gains a row saying which company, on what date, and whether the grant is still active. If you leave in a year, you revoke it from there.
The protocol underneath that story is real and in production. A business we have onboarded opens a session with its declared list. A person claims it on the web, on their phone, or through their AI. The AI reads the ask and proposes items. The person approves in the iPhone app, and only the phone can approve: the five connection tools we give your AI are claim, list, read the ask, propose, and check status. There is no approve tool, so your AI cannot authorize anything on your behalf.
What comes back to the employer is the approved set plus a receipt id and a revocable grant id, and every one of those pieces is code that runs, not a diagram.
The story above is the shape, not a feature you can trigger. No employer manifest exists in ShareLess today. The single setup request we run in production is a tool-setup one, and it asks for sources a piece of software should watch, not for anything an employer would need. A payroll version would be written with a design partner, and it does not exist while this sentence is here.
The appealing part of the story is that the AI fills in what it can and bothers you only about the rest. There is no channel for that. A proposal is all or nothing: your AI submits the items it found, and there is no way for it to mark one as unresolved and hand that single question back to you. Your inputs are to approve or reject each item, to leave anything counted as content switched off, and to change whichever settings the business marked modifiable, such as how long it says it will keep what you send. Building the gap channel is ahead of us, not behind us.
The approval sheet groups an ask into the categories the business declared, including a block showing what it promises never to ask for. Both halves of that now exist: the server sends the categories where the app reads them, and the app knows how to render them. What decides whether you see it is your app build, because the grouping landed after the build currently out with pilot testers. Until you update, the sheet falls back to a flat list of items, which is accurate and complete but not grouped.
An employer cannot sign up for this. Business keys are matched against an allowlist in our deployment environment, edited by an operator, and every unrecognised key is refused. On your side, approval happens in the iPhone app, which is on invite-only TestFlight rather than the App Store, and Android cannot approve a connection at all. Your AI also needs the ShareLess connector added before it can read an ask.
A connection release is stored on ShareLess servers so the employer can pull it, and the items in it passed through whichever AI you asked to do the work. That is a different trust model from the ShareLess vault, which is a file on your phone. We do not describe a connection as staying on your device, because it does not.
Revoking marks the grant revoked in your ledger and records the moment. The next time the employer pulls that session, it is told the grant was revoked and when. ShareLess does not phone them, and it does not sit between the employer and the copy they already hold, so it cannot retrieve it. Revocation is a signal the recipient is expected to honour. Their own systems are where their access actually ends.
Because the alternative is worse in a way people have stopped noticing. The reason a new hire emails a whole bank statement is that there was no way to hand over a routing number and an account number by themselves. The employer did not want the rest; they just had no way to ask for less, and now they have a document they must secure for years.
A declared list fixes the asking. The part we have not built is the answering: a business declaring the least it will accept, and your side answering there instead of at the maximum. That is the middle of our spine, and it is the honest reason this page has as many caveats as it does.