Delegated access

You publish manuals your customers pay to read. Their IT lead keeps emailing you to add one more person. You do not want to make them an admin of your workspace, and you do not want to keep being the bottleneck.

Delegated access hands them the decision, and nothing else: they admit their own people, read-only, and only to the groups you opened. You keep the last word on what can be read; they take over who reads it.

Why it is not a share link

The obvious alternative — send a link — does not work for content that is confidential and paid for. A link is a bearer: whoever holds it reads, signed in or not, forever, and forwarding it costs nothing. So no link is created anywhere in this flow. Everyone admitted signs in as themselves, and access can be withdrawn from a named person.

What the owner controls

You grant delegation from Dashboard → Members, or:

blenau delegation grant <member-id> --allowance 10 --group <group-id>

Two things you set, and they are the whole of your exposure:

• Which groups they may hand out. Only groups you have opened to the customers audience can be delegated — otherwise a customer could admit someone into a staff group. Open a group in Dashboard → Groups.
• How many people they may admit here (--allowance, default 3). 0 means “granted, but blocked”: they still see the surface and know who to ask, instead of a screen that looks broken.

Two things you do not set, because they are fixed:

• Everyone they admit is read-only. Always. The delegate chooses who, never what level.
• They can only hand out groups they themselves belong to. The effective scope is the intersection with their own access, recomputed on every request — so if you narrow their access later, what they can share narrows with it, automatically. A grant can never outlive the permission it came from.

Seeing what they did

blenau delegation tree

or the Admitted by your customers panel on the Members page. Their decisions are your exposure: someone admitting forty people to your confidential manuals should not be something you find out from an invoice.

What it costs you: nothing

People admitted by a delegate do not consume your reader seats. They live in your workspace and read your content, but the seat is billed to the delegate’s own Blenau plan.

That is deliberate. If your plan drained every time a customer added someone, your cheapest defence would be to switch delegation off — and then nobody would use it.

What the delegate sees

Their side is Dashboard → Access, or blenau access:

blenau access quota                    # both limits, and which one is blocking
blenau access admit [email protected] --group <group-id>
blenau access list
blenau access withdraw <admission-id>

Two limits apply and the smaller one wins:

Limit	Who sets it	Scope
Allowance	the workspace owner	this workspace only
Delegated seats	the delegate’s own Blenau plan	every workspace they were delegated in

The plan limit is global on purpose. If someone is a customer of three suppliers and each grants them 20, that is 60 real people — counting only their global footprint is what stops one plan from being multiplied by every supplier they connect to.

blenau access quota names which limit is binding, in a binding field:

• plan — buying a bigger Blenau plan raises it.
• owner — it does not. Only an admin of that workspace can, and blenau access request-more asks them. Blenau will not offer you an upgrade here, because paying would leave you exactly as blocked.
• owner_billing — that workspace’s subscription is inactive. Neither side’s plan changes it; an admin there has to restore billing. Everyone already admitted keeps reading.

Seats without a workspace of your own

A delegate does not need a Blenau workspace to start — without one you get 3 seats across all workspaces. To go past that you create your own workspace and pick a plan, which is one step in the dashboard, and you get your own brain and agent with it.

Ending it

blenau delegation revoke <member-id>                # cuts off them AND their people
blenau delegation revoke <member-id> --keep-branch  # you adopt their people as your readers

Revoking cascades by default: that is the usual meaning of “this customer is gone”, and it is one action instead of removing their people one at a time. --keep-branch instead adopts them as your own readers — they keep reading, and from then on they count against your reader seats.

A delegate can also withdraw anyone they admitted, at any time. Whoever creates a state has to be able to undo it.

Neither form deletes anyone, and that is on purpose: who admitted whom is the first question any access review asks, and deleting the record makes it unanswerable. If you try to delete a delegate outright while their branch is alive, Blenau refuses and offers you the three real ways out rather than silently rewriting their people into “admitted by the owner”.

Available where

Surface	Owner side	Delegate side
Web	Members page	Dashboard → Access
CLI	blenau delegation	blenau access
API	/members/{id}/delegation, /delegation/tree	/delegation/*
MCP	delegation_tree, set_delegation_allowance	—

The delegate’s lane is not an MCP surface, and that is a decision rather than an omission: admitting someone is a nominal act, and a principal of an external audience cannot hold a long-lived machine token in the first place. Use the CLI signed in as yourself.