Skip to main content

Auto-route identity tickets

Canonical workflow: Auto-route identity tickets

Canonical identity / app: sn-ticket-router

Systems in scope: ServiceNow, Microsoft Entra / Graph, Microsoft Foundry

Canonical Demo Brief​

What happens​

A new identity-related incident or request lands in ServiceNow.

The workflow Auto-route identity tickets runs under the non-human identity sn-ticket-router, pulls user and group context from Microsoft Graph, sends selected ticket and identity context to Microsoft Foundry for classification, and writes the recommended route and priority back into ServiceNow.

Why it is common​

This is normal enterprise plumbing.

Service desks already auto-route tickets. Identity teams already enrich tickets with Entra context. Platform teams already add Microsoft AI services to improve triage speed. Nothing about this flow requires unusual behavior or a contrived threat model.

Why existing tools miss it​

Each system only sees its own fragment.

ServiceNow shows the workflow ran. Entra shows the app and its scopes. Foundry shows a model call. None of them reconstruct the live access chain end to end, show the exact authority used, and explain what changed on that same running path.

What changed​

Three structural changes happened on the live path:

  • the Graph side drifted from the narrower baseline to broader read reach, including Directory.Read.All
  • the workflow no longer has a valid accountable owner; the owner record tied to the router branch is stale or disabled
  • Microsoft Foundry was added after baseline and is now part of the same production execution

Why it matters​

This is execution exposure, not posture trivia.

The workflow still runs. It now runs with broader directory reach, no valid accountable owner, and a new model egress step on the same path. That means the enterprise has a live classification workflow operating under authority that no longer matches the original intent.

What SecurityV0 shows​

SecurityV0 shows one real execution:

  • what actually ran: Auto-route identity tickets
  • under whose authority: sn-ticket-router
  • what access chain it used across ServiceNow, Graph, and Microsoft Foundry
  • what changed on that same live chain
  • what needs action now

What to remediate​

Keep the fix bounded to the path that ran:

  • reduce Graph access from broad directory read to only the user and group reads needed for routing
  • assign one current accountable owner to the workflow and the sn-ticket-router app
  • review the Foundry step and keep only the minimum routing fields needed for classification; if that is not approved, remove the Foundry hop from this workflow

Demo Talk Track​

Opener / problem framing​

"Most teams can tell you this ticket router exists. They usually cannot show the exact production path it ran, under whose authority it acted, what changed on that path, and whether it should still be allowed to run this way."

What just ran​

"A new identity ticket hit ServiceNow. Auto-route identity tickets executed, used sn-ticket-router, pulled requester and group context from Microsoft Graph, sent the routing context to Microsoft Foundry, and wrote the route and priority back into ServiceNow."

Provenance / proof​

"We can prove each hop. ServiceNow shows the workflow execution and ticket update. Entra shows the sn-ticket-router identity and Graph scopes. The Graph branch shows the actual read reach. Foundry shows the classification step. SecurityV0 puts those proofs into one access chain."

What changed on the live path​

"This same workflow did not start here. The Graph side expanded beyond the original routing scope. The owner on the router branch is no longer valid. And Microsoft Foundry was added after baseline, so model egress is now part of the production path."

Why this is execution exposure​

"This is a live workflow making decisions on real tickets with authority that drifted. The problem is not that permissions exist somewhere. The problem is that this exact path really runs, and it now runs with broader reach and weaker accountability than intended."

Bounded remediation​

"We do not need a platform rewrite. Narrow the Graph scopes, assign a real owner, and either approve the Foundry classification step with minimum routing context or take that hop out of the workflow."

Close​

"SecurityV0 is not another place to review permissions. It shows what actually ran with delegated authority, what changed on that live path, and what needs action now."

Technical Setup Brief​

Exact nodes​

Use these labels in product:

  • Auto-route identity tickets — workload
  • incident — resource
  • Graph - sn-ticket-router — connection
  • Azure Graph OAuth Client — credential
  • sn-ticket-router — identity
  • Microsoft Graph role set — role group
  • Microsoft Graph: User.Read.All — permission
  • Microsoft Graph: Group.Read.All — permission
  • Microsoft Graph: Directory.Read.All — permission
  • Microsoft Foundry classification — resource
  • Current owner invalid — owner state

Exact edges​

  • incident TRIGGERS_ON Auto-route identity tickets
  • Auto-route identity tickets INVOKES Graph - sn-ticket-router
  • Graph - sn-ticket-router USES Azure Graph OAuth Client
  • Auto-route identity tickets RUNS_AS sn-ticket-router
  • sn-ticket-router HAS_ROLE Microsoft Graph role set
  • Microsoft Graph role set GRANTS Microsoft Graph: User.Read.All
  • Microsoft Graph role set GRANTS Microsoft Graph: Group.Read.All
  • Microsoft Graph role set GRANTS Microsoft Graph: Directory.Read.All
  • Auto-route identity tickets SENDS_TO Microsoft Foundry classification
  • Auto-route identity tickets WRITES_TO incident
  • Auto-route identity tickets OWNED_BY Current owner invalid

Labels / names to use in product​

Prefer these display names over the raw pull where possible:

  • AzureGraphRouter or AzureGraphRouterNoOwner -> Graph context step
  • automation_disabled_owner -> Current owner invalid
  • hashed Microsoft Graph role labels -> Microsoft Graph role set
  • duplicate OAuth credential labels -> collapse into one Azure Graph OAuth Client proof object unless expanded

What to highlight​

Highlight these elements in the primary click path:

  • Auto-route identity tickets
  • sn-ticket-router
  • Microsoft Graph: Directory.Read.All
  • Microsoft Foundry classification
  • Current owner invalid

Findings to attach to this execution​

Attach only these three findings:

  • Graph scope drift on live path — the path now includes broader Graph read reach than baseline
  • No valid accountable owner — the workflow and router branch no longer resolve to a current owner
  • Foundry added after baseline — model egress is now part of the executed path

Exact remediation actions to show​

  • Reduce sn-ticket-router Graph access to the minimum routing scopes
  • Assign one accountable owner for Auto-route identity tickets and sn-ticket-router
  • Approve Microsoft Foundry for ticket routing with minimum routing context, or remove it from this workflow

Seller Prep​

What to say​

"This is one live production workflow, not a scanner finding. We show the exact access chain it used, under whose authority it ran, what changed on that path, and the three actions needed to bring it back inside intent."

Why the buyer should care​

The workflow is easy to recognize, easy to explain, and hard to reconstruct across tools.

It turns a vague AI-governance conversation into one provable operational question: should this production workflow still be allowed to run with this authority and this new egress step?

Where this lands​

For a CISO:

  • proof that a real AI-connected workflow is running with drift and broken accountability

For an IAM lead:

  • exact identity, Graph scopes, and the narrowest authority change needed now

For a platform owner:

  • one bounded workflow fix, not a platform-wide redesign