Secret codes
Some identity actions hand a locked-out employee a password, an access code or a recovery key. Siit delivers that value privately, shows everyone else only that a code was issued, and takes it back wh
A few actions produce a value that only one person should ever read: a JumpCloud temporary password, an Okta temporary access code, the FileVault or BitLocker recovery key of a computer. Siit calls those secret codes and handles them differently from every other action result.
The code goes to the employee it belongs to, through a private channel. Nobody else sees it — not the request thread, not the AI agent, not the workflow history, not an export. Everyone else sees an event saying a code was issued, who it went to, and when it expires.
Actions that issue a code
Generate temporary password
JumpCloud
A password Siit generates, which must be changed at next sign-in
Create temporary access code
Okta
A single-use code that lets them enrol a new authenticator
Recovery Key
JumpCloud, Jamf, Iru
The FileVault or BitLocker key escrowed for their computer
Recovery Key
Intune
The BitLocker key of their computer's operating system volume
Recovery Lock Password
Jamf, Iru
The Recovery Lock password of their Apple silicon Mac
Each one runs from the request side panel and from the person or equipment page. All except Intune's Recovery Key also run from a workflow and from an IT Agent playbook. Like every integration action, it can be gated behind an approval.
Not every provider offers every surface:
JumpCloud
Recovery Key
Yes
Yes
Iru (Kandji)
Recovery Key, Recovery Lock Password
Yes
Yes
Jamf
Recovery Key, Recovery Lock Password
Yes
Yes
Intune
Recovery Key
Yes
No
Intune reads the BitLocker key as the admin who is signed in, so it is offered on the pages you open yourself and not to an agent or a workflow, which have nobody to sign in as.
How the code reaches the employee
Siit picks the private channel the employee already uses.
Slack
A direct message from the Siit app, behind a Reveal button
Microsoft Teams
A personal chat, behind a Reveal button
Portal or the admin console
A reply on the request that only the requester can open
The Reveal button opens the value in a Slack modal or a Teams dialog, so it never enters channel history, an export, or a message event. Only the person the code was issued for can reveal it, and only while it is still valid.
When an agent is talking to an employee in a public channel, Siit sends the code to that person's direct message and the agent says so in the thread. The code itself never appears in the public conversation.
What everyone else sees
Every issuance writes a Secret code issued event on the request feed and on the person's and the computer's timeline. The event names the code, the recipient, where it was delivered and when it expires — never the value.
A chat delivery reads sent by Slack direct message, deleted when it expires.
A delivery in the request reads posted on this request for the requester only, hidden when it expires.
A code an admin revealed to themselves says neither: nothing expires visibly, because the admin holds it.
The same event reaches the requester's thread and the public thread of the request. It never goes to followers, to admins, or to email.
Fetching a recovery key or a Recovery Lock password through Jamf, Iru or Intune writes these events too. Those fetches previously left no trace on the request at all.
Expiry
A code lives for 60 minutes by default. Siit can set a different lifetime for your workspace, up to a maximum of 24 hours.
When the code expires, Siit takes it back:
the encrypted value is deleted;
the Slack or Teams message carrying it is deleted;
a reply posted on a request is rewritten to
[code expired];anywhere the code was referenced — agent history included — reads
[code expired].
Okta is the exception: Okta sets its own expiry on a temporary access code and that expiry wins, whatever your workspace lifetime says.
Issuing a code from a request
Open the request, find the integration block in the side panel, and run the action.
For a JumpCloud password reset you choose between letting Siit generate the password and typing one yourself:
Generated — Siit creates the password and sends it to the requester. You can also reveal it once, with a copy button, if you would rather read it out yourself.
Typed — you supply the password. A password you typed is never shown back to you, and Siit sends it to the requester the same way.
If the send to the requester is refused or fails, Siit shows you the code once instead and records that you revealed it. On any other error the code stays where the employee can still reach it and is never shown to you.
For a device secret, the action opens a short dialog where you choose what happens to it:
Send it to the requester privately — the secret goes to them and only them, through their Slack direct message, their Teams personal chat, or a reply on the request only they can read. You never see it.
leave that off and the secret is shown to you once. Copy it before you close the dialog; Siit does not show it again.
A device Siit holds for one person but whose MDM owner is somebody else cannot be sent to the requester. You can still reveal it to yourself, because then you are the recipient.
Issuing a code from a workflow
A workflow step that issues a code sends it itself. There is no separate send action to add after it.
Because of that, the step needs somewhere private to send to:
it runs on Request and App access workflows, where there is a requester and a thread;
it fails before the provider is ever called when the request has no private channel;
a People workflow has no request to send through, so it does not offer a generated code.
The failure is reported on the workflow run like any other step error, and no code is issued.
Related: JumpCloud · Okta · Jamf · Iru · Intune · Actions library
Last updated