Worker

Approving new workers

By default, a worker that connects with one of your organisation's worker keys starts serving straight away. If you'd rather see a machine before it does anything, you can require new workers to be approved first.

A worker waiting for approval is connected but idle. It shows on the Workers page as Awaiting approval, streams its logs, and reports its hardware — so you can look at exactly what turned up before deciding. It receives no requests, and it does not occupy one of your plan's worker slots while it waits. Your plan limit does still apply when it connects, so if you are already at the limit you'll need to free a slot before a new worker can connect for you to review.

Approving is also a key decision

Approving a worker does two things: it starts routing requests to it, and it qualifies it to be given your organisation's encryption key by the workers you already have. That is deliberate — "what is running my traffic?" and "what holds my key?" should have the same answer.

So a worker you don't approve never receives your key. Rejecting one is not a disconnect: it stays connected and serving nothing, and you can approve it later without touching the machine. If it had already been given a key, rejecting it takes that key back out of its memory — unless it is the only worker still holding that key, because dropping the last copy would delete your organisation's key outright and stop private inference everywhere. In that case retire that fingerprint on the Encryption page when you're ready: retiring clears it from the rejected worker's memory, and the next worker to connect creates a fresh key for your fleet. A rejected worker is never given that new key.

Turning it on

In the console, open Encryption and turn on Worker approval. It's off by default, and any owner or operator can change it.

It's a setting in its own right — nothing else switches it on or off. In particular it is independent of enforcing end-to-end encryption, which sits on the same page: that decides whether plaintext requests are allowed, this decides who is allowed to join your fleet. Most organisations want both, but you can have either on its own.

Workers already connected when you switch it on are approved automatically. The fleet that is already running is the fleet you already trust; approval is about what turns up next, so turning it on never stops your own traffic.

Turning it off again releases anything still waiting: those workers start serving straight away and are given your encryption key, without you touching the machines. A worker you rejected is released too — with approval off you are no longer vetting machines — but the rejection itself is remembered. Turn approval back on and that worker goes straight back to Awaiting approval: it stops serving and the key is taken back out of its memory, without waiting for it to reconnect. A "no" survives the round trip.

GPUs you rent from Pendra

Rentals approve themselves. You ordered the machine, which is the authorisation — and waiting for a second confirmation would defeat the point of renting capacity for a few hours. The approval is bound to the worker key Pendra issued for that rental, so it applies to that machine and nothing else.

Approving a worker

On the Workers page, a pending worker shows Approve and Reject next to its status. That is the whole flow — one click, no configuration on the machine.

Or do it directly: 

curl -X POST https://api.pendra.ai/api/v1/workers/<worker_id>/approval \
  -H "Authorization: Bearer <your session token>" \
  -H "X-Org-Id: <your org id>" \
  -H "Content-Type: application/json" \
  -d '{"approved": true}'

It takes effect immediately — the worker starts receiving requests, and your fleet gives it the encryption key without you doing anything on the machine itself. Send false to reject; the worker stays connected and idle, so you can approve it later without touching the machine.

Every approval decision your team makes is recorded. A worker's Activity tab shows when it was approved or rejected and which member of your team did it. Turning approval on or off is recorded the same way on each worker it affects — the workers approved automatically because they were already connected, and the workers released when you turned it off — attributed to whoever flipped the switch.

Next