Employee onboarding and offboarding automation is high impact because it touches identity, access, and licensing. In Claw EA, you run the workflow as an OpenClaw baseline agent runtime job, but you do not rely on “the prompt” to keep it safe.
Instead, you permission the execution layer with a WPC (Work Policy Contract) and issue a CST (scoped token) per job, so actions like creating accounts, disabling accounts, and assigning licenses are gated by policy, approvals, and verifiable receipts.
Step-by-step runbook
-
Define the onboarding and offboarding action surface, and mark irreversible actions as high risk. At minimum treat “create account,” “disable account,” and “assign licenses” as high risk, even if they are routine.
Decide what must be done via Microsoft Graph (via official API) and what can be done via internal systems (often via an MCP server or an enterprise buildout).
-
Create a WPC that describes the allowed tools, allowed Graph permission scopes, and approval requirements. Store the signed, hash-addressed policy in the WPC registry (served by clawcontrols) and reference it by its policy hash.
This makes “what the agent is allowed to do” machine-checkable and stable, even if prompts or skills change.
-
Issue a CST (from clawscope) that is scoped to this workflow and pinned to the WPC hash. Bind the CST to the job to prevent replay across runs (marketplace anti-replay binding).
Use short TTLs and per-run tokens so a leaked token is less useful and older runs cannot be re-executed later.
-
Configure OpenClaw tool policy and sandboxing for the job. Keep tools minimal, prefer sandboxed execution for any file or process tooling, and avoid host-elevated tools unless you have an explicit need.
Run the OpenClaw security audit regularly as part of the workflow’s operational checklist, especially after config changes.
-
Implement step-up approvals and the two-person rule for high risk actions. Practically, this means the agent can prepare a plan and a “pending change set,” but a second approver must confirm before execution proceeds.
If you already use Conditional Access and PIM in Microsoft Entra, align approvals with your existing operational pattern, for example requiring a privileged operator approval before license assignment or account disable.
-
Isolate secrets and credentials. Keep Microsoft Graph credentials and any internal system credentials out of prompts and skill text, and only make them available at execution time to the specific tool that needs them.
Pair this with CST scoping so the job can call only the allowed proxy and policy services, not arbitrary endpoints.
-
Route model traffic through clawproxy to obtain gateway receipts, then produce a proof bundle at the end of the run. Store or attach the proof bundle to the ticketing or HR case record, and optionally publish a Trust Pulse for audit viewing.
This gives you a concrete artifact for “what was asked, what was executed, and under which policy,” without relying on ad hoc logs.
Threat model
Onboarding and offboarding workflows fail in predictable ways: overbroad permissions, ambiguous approvals, and tool access that exceeds intent. The goal is to keep the agent useful while making unsafe paths fail closed.
| Threat | What happens | Control |
|---|---|---|
| Prompt injection triggers unauthorized identity changes | An email, chat, or ticket includes text that tricks the agent into disabling the wrong user or changing a privileged group. | WPC tool and action allowlists, step-up approvals for high risk actions, and two-person rule before commit. |
| Overbroad Microsoft Graph permissions or role scope | The workflow token can edit more users or groups than intended, turning a single mistake into org-wide impact. | WPC declares allowed Graph scopes and limits target selectors; CST is pinned to the WPC hash and issued per job. |
| Credential leakage into logs or prompts | Secrets appear in model context, transcripts, or tool output, and then spread to downstream systems. | Secrets isolation at execution time; OpenClaw logging redaction hygiene; keep credentials out of skill text and prompts. |
| Replay of a prior “disable account” run | An attacker reuses old authorization material to re-run offboarding actions or execute them out of window. | Job-scoped CST binding (anti-replay) and short TTLs; require fresh approvals per run. |
| Unverifiable model actions during incident review | You cannot prove what the model call contained, which model was used, or whether the proxy enforced policy. | Gateway receipts from clawproxy and proof bundles for verification and post-incident reconstruction. |
Policy-as-code example
This is a sketch of what a WPC-driven onboarding/offboarding policy can look like. The point is to make the “allowed actions” and “approval gates” explicit, rather than hoping the agent follows instructions in a prompt.
{
"wpc_version": "v1",
"workflow": "employee_onboarding_offboarding",
"risk_classes": {
"high": [
"create_account",
"disable_account",
"assign_license"
]
},
"approvals": {
"step_up_required_for": ["high"],
"two_person_rule_for": ["high"],
"approval_evidence": ["ticket_id", "approver_1", "approver_2", "timestamp"]
},
"identity_targets": {
"allowed_tenants": ["TENANT_ID_PLACEHOLDER"],
"allowed_user_match": ["hr_employee_id", "userPrincipalName"],
"deny_if_ambiguous_match": true
},
"graph_policy": {
"via": "official_api",
"allowed_scopes": [
"User.ReadWrite.All",
"GroupMember.ReadWrite.All"
],
"deny_operations": [
"roleAssignment.write",
"directoryRole.activate"
]
},
"execution": {
"openclaw_tool_profile": "onboarding_minimal",
"sandbox": "on",
"elevated_tools": "deny"
},
"attestation": {
"require_gateway_receipts": true,
"require_proof_bundle": true
}
}
In practice, you align this with Microsoft Entra controls, including Conditional Access and PIM for privileged operations. If your environment requires additional gates like manager verification or HRIS reconciliation, that is typically handled via an MCP server or enterprise buildout tied into your existing system of record.
What proof do you get?
Each run can produce gateway receipts for model calls, emitted by clawproxy. These receipts are designed for verification so you can later show that model traffic flowed through the proxy path you control, under the CST and the pinned WPC hash.
At the end of the run, Claw EA can assemble a proof bundle that packages the receipts and related metadata needed for audit and verification. If you use OpenRouter via fal routed through clawproxy, the model call receipts still come from the same controlled gateway path.
For audit workflows, the proof bundle can be stored as a Trust Pulse artifact for viewing. This helps answer operational questions like “who approved the disable,” “which policy version was active,” and “what model interactions occurred,” without depending on a single mutable log stream.
Rollback posture
Identity workflows have asymmetric rollback: some changes are reversible, others are not, and some are only reversible within a time window. Your rollback plan should be part of the WPC and the runbook, not an afterthought during an incident.
| Action | Safe rollback | Evidence |
|---|---|---|
| Create account | Disable the new account, remove group memberships, revoke sessions, and open a ticket for follow-up identity review. | Proof bundle showing the create request plan, approvals, and the gateway receipts for model calls used to generate the change set. |
| Assign licenses | Remove licenses, verify mailbox and data retention implications, then document impact in the ticket. | WPC hash for the run and approval evidence captured before commit, plus receipts confirming the controlled execution path. |
| Disable account | Re-enable only with step-up approvals, then force password reset or session revocation based on your incident posture. | Two-person approval record tied to the job-scoped CST binding, to show the disable could not be replayed outside the run. |
| Group membership changes | Restore from last-known-good membership snapshot, then verify app access and Conditional Access behavior. | Run artifact trail: policy hash pinning, receipts, and the recorded target selectors used for the change. |
For stronger rollback, many teams add a “dry-run then commit” pattern, where the agent produces a proposed diff and waits for approvals. That pattern maps cleanly to step-up approvals and the two-person rule, without granting the agent authority to commit irreversible actions by itself.
FAQ
Why is permissioned execution better than prompt-only controls?
Prompts can be overwritten by input text, tool output, or a model mistake. A WPC makes allowed actions and required approvals enforceable by the execution layer, so the system fails closed when the agent tries to go out of bounds.
How does this interact with Microsoft Entra ID and Microsoft Graph permissions?
You typically execute identity actions via official API using Microsoft Graph, with scopes limited to what the workflow needs. The WPC documents and constrains those scopes, and approvals are required before high risk operations like account disable or license assignment.
What enforces the two-person rule in practice?
The agent can prepare a change set and request approvals, but execution is blocked until two distinct approvers are recorded for the specific job. This is most reliable when approvals are tied to your ticketing workflow and verified before commit.
What stops someone from replaying an offboarding run later?
CSTs are issued per job and can be bound to the job to prevent replay. Combined with short TTLs and policy hash pinning, older authorization material does not remain valid for new runs.
What do auditors get at the end of the workflow?
You can provide gateway receipts for model calls and a proof bundle that packages receipts with run metadata. If you use Trust Pulse, you can store the artifact for later viewing during audits or incident review.