Close offboarding gaps: governed deprovisioning across legacy apps

Autom Mate Platform
, , , ,
1

Problem: “AI said to offboard them”… but access still lingers in legacy apps

A common ITSM failure mode: the service desk closes the offboarding ticket, Entra ID is disabled, but app access remains in places that aren’t cleanly tied to identity governance (local DB auth, old admin panels, vendor portals, etc.). That leaves orphaned accounts and audit findings.

This is exactly where AI-only approaches are risky: an AI agent can suggest “remove access everywhere,” but it can’t safely take direct action across systems without policy checks, approvals, deterministic execution, and an audit trail.

This topic proposes using Autom Mate as the execution + control layer between AI/ITSM and the actual systems.

End-to-end workflow (ticket → governed execution)

1) Trigger

  • ServiceNow (or Xurrent/Freshservice/HaloITSM) offboarding request moves to a specific state, e.g. Ready for Deprovision.
  • Autom Mate starts an Autom via:
    • Autom Mate library: ServiceNow (preferred if available in your environment), OR
    • REST/HTTP/Webhook action: ServiceNow outbound webhook → Autom Mate API trigger (context + policy checks)
  • Pull required context from the ticket:
    • user UPN/email, employee ID, termination date/time, manager, cost center
    • “systems in scope” (from catalog item variables)
  • Policy checks before any action:
    • confirm ticket type is “Leaver” (not “Mover”)
    • confirm requester is HR/PeopleOps or authorized role
    • confirm termination date is not in the future
    • confirm user is not in protected groups (e.g., break-glass, exec exceptions)
  • Autom Mate implements these as deterministic validation + conditional steps (no guessing), with built-in error handling paths

3) Approval (- If the user has elevated access (e.g., privileged groups, finance apps, production tools), require explicit approval:

  • manager approval + app owner approval
  • Approval request sent to:
    • Autom Mate library: Microsoft Teams or Slack (preferred), OR
    • REST/HTTP/Webhook action: post to Teams/Slack webhook
  • Approval outcome is written back to the ITSM ticket as a comment/state change.

4) Deterministic execution across systems

Autom Mate executes a fixed runbook (not an AI free-for-all):

  • Step A: Entra ID hardening

    • disable sign-in
    • remove from high-risk groups
    • revoke sessions/tokens
    • (optional) convert mailbox / remove licenses
    • Integration:
      • REST/HTTP/Webhook action: Microsoft Graph calls (fallback)

  • Step B: Legacy app deprovisioning (the usual gap)

    • for each “legacy app” listed in the ticket (or CMDB mapping), call the app’s deprovision endpoint:
      • disable local account
      • remove roles
      • rotate any user-owned API keys
    • Integration:
      • REST/HTTP/Webhook action: internal app APIs
      • Autom Mate library: Database action (if the legacy app is backed by a DB and you have a safe stored procedure path)

  • Step C: Evidence pack + closure

    • write a structured “deprovision summary” back to the ticket:
      • what was removed, when, by which Autom version
      • what failed and why
      • links/IDs for each system action

5) Logging / audit

  • Autom Mate records execution logs and supports monitoring views for traceability .
  • For stricter environments, logs can ben stack (e.g., Elasticsearch) .
  • Bonus governance: track which Autom version executed theful when auditors ask “what changed?”) .

6) Exception handling / rollback

  • If a downstream system fails (API 500, ra:
    • Autom Mate routes into an error handler: retry with backoff, alert on-call, and keep the ticket open with a “Partial deprovision” status .
  • Rollback strategy (where safe):
    • if Entra disable succeeded but app deprovision failed, **do not rinstead create a child task for app owner + keep the account disabled.
    • if a role removal step fails mid-way, re-run idempotently (desired state = “no access”).

Two mini examples

Mini example 1: “Offboard contractor, but keep mailbox for legal hold”

  • Trigger: ServiceNow offboarding request
  • Validation: user is contractor + legal hold flag present
  • Approval: HR approval only
  • Execution:
    • disable Entra sign-in
    • remove from all access groups
    • skip mailbox deletion; keep mailbox + set forwarding to manager
    • call 3 legacy apps’ REST endpoints to disable local accounts

Mini example 2: “Leaver had production access—require app-owner approval”

  • Trigger: ticket state = Ready for Deprovision
  • Validation: user is in “Prod-Deployers” group
  • Approval: manager + platform owner in Teams
  • Execution:
    • revoke sessions immediately
    • remove prod roles in CI/CD tool via REST
    • rotate any user-scoped tokens
    • post evidence back to ticket

Why this is an AI governance issue (not just automation)

  • AI is great at identifying what should happen, but it’s risky to let AI directly mutate identity and app permissions.
  • You want:
    • deterministic runbooks
    • explicit approvals for high-risk actions
    • policy checks before execution
    • complete audit logs + versioned workflows
  • Autom Mate fits as the execution + control layer that turns “AI intent” into governed, repeatable actions across systems .

Discussion questions

  • Where do your orphaned accounts usually hide: legacy apps, vendor portals, shared admin phadow IT?
  • Do you require app-owner approval for deprovisioning in high-risk systems, or is manager approval enough?