Compute
Define a service identity
A service identity needs a current human owner, a project, a workflow, its destinations, an expiry and a budget. Offboarding a person and transferring an identity are different acts.
Before you start
You need administration authority, one automation that has a job to do, and a person willing to own it. A service identity without a named owner is an orphan waiting to happen.
Register the sources and destinations it will use first. An identity is easier to scope once you know exactly what it touches.
Require all six facts
A service identity is not defined until all six of these are recorded. Missing one is how a credential outlives its purpose.
- A current human owner, who answers for what this identity does.
- A project, so its spend and its results belong somewhere.
- A workflow, so its work is bounded to what it exists to do.
- Its destinations, named explicitly rather than inherited.
- An expiry, after which it stops rather than continues.
- A budget, so it cannot outspend its purpose.
Set the expiry to the period you would actually review, not the longest one you can. A distant expiry is a review you have quietly decided to skip.
Register it like any other resource
The identity family follows the same lifecycle as everything else. Plan the identity, create it, then read it back before anything uses it.
The plaintext secret is revealed once, during protected setup. Store it immediately; it cannot be retrieved later.
Confirm the read-back shows the owner, project, workflow, destinations, expiry and budget you intended. A missing field here is a missing control in production.
Keep it narrower than its owner
A service identity can only narrow the authority of the person who owns it. It never holds a grant its owner does not.
That has a consequence people miss. When the owner's own authority is reduced, the identity is reduced with it, and work that relied on the wider grant starts refusing.
A work automation gets a work key. An administration automation gets a management service identity, admitted separately. See what each grant can hold before you choose.
Offboarding is not a transfer
Removing a person and transferring an identity are two different acts with different consequences. Doing one does not do the other.
Removing a member suspends and removes their own grants. It does not reassign the service identities they owned, and it does not stop those identities running.
An identity whose owner has left has no current human owner. Transfer it to a named owner, or revoke it. Do not leave it running while you decide.
Plan the transfer, apply it, then read the identity back and confirm the new owner is recorded. The events should show the change with a time you recognize.
Confirm success
The identity reads back as VERIFIED, with the owner, project, workflow, destinations, expiry and budget you set.
One real submission from the automation succeeds. One submission outside its workflow or its budget refuses. If both succeed, the scope is wider than you think.
When it expires or refuses
An expired identity refuses with a reason and a next action. That is the control working, not a fault.
Renew it deliberately, as a decision, after checking the automation still needs the same scope. Renewal is a good moment to narrow something.
CANONICAL_BUDGET_EXHAUSTED means the identity's budget is used up, not that it lost authority. CANONICAL_ADMISSION_LIMITED means it is not authorized to make that request at all, which is a grant problem.