Interactive ticket trace

Intake & classification

The Incident lands in the orchestrator's queue, exactly as it would for a human tier-1 tech. The orchestrator reads the short description and the caller record, classifies the ticket (Incident · identity domain · P3), resolves the affected principal to CORP\dmorgan, and opens a trace_id that every message about this ticket will carry. No system has been touched yet — this stage only reads.

Enrichment

The identity agent gathers state. Reading directory attributes and event logs is read-only, so it runs unattended at Tier 0 with nothing to approve. It pulls the account, the lockout policy, and the last few authentication events, and correlates them.

account:          CORP\dmorgan
lockoutTime:      2026-08-27T14:02:07Z   (locked)
badPwdCount:      7
lockoutThreshold: 5 in 15 min           (policy)
lockoutDuration:  30 min                (policy)
pwdLastSet:       2026-08-27T14:01:12Z   (self-service change, ~1 min before lockout)
lastGoodAuth:     14:01:20  device LT-4471  (registered to dmorgan)
badPwdSource:     14:01:33-14:02:07  device TB-2290  (registered to dmorgan)
groupMembership:  Server Operators, Platform-Eng, All-Staff
mfaState:         enrolled, healthy

The pattern reads as a cached credential, not an attack: the bad passwords all came from one device the user owns, seconds after a successful password change, with no geo-anomaly and MFA intact.

Draft a plan

The identity agent turns that state into a concrete plan with a paired rollback and hands it back to the orchestrator as a proposal message on the bus. Domain agents propose; they never decide. The envelope fields (trace_id, causation_id, sig, and the rest) are defined on the agent-to-agent protocol page; the type-specific body is below.

"type": "proposal",
"ticket_id": "INC0104729",
"from": "agent.identity",
"to": "orchestrator",
"payload": {
  "plan_id": "PLAN-3",
  "steps": [
    "unlock CORP\\dmorgan on the nearest writable domain controller",
    "set 'user must change password at next logon'",
    "verify: account unlocked AND test bind succeeds AND badPwdCount == 0"
  ],
  "rollback": "re-lock the account, page identity on-call, attach this trace",
  "blast_radius": { "principals": 1, "systems": 1 },
  "reversible": true,
  "notes": "principal is in a protected group (Server Operators)"
}

Risk-tier decision

The orchestrator scores the plan. Blast radius is tiny and the rollback is clean, which by itself would land at Tier 1 (auto-execute, logged). But the plan mutates a directory object, and the principal sits in a protected group — and policy sets a floor of Tier 2 for any mutating action on a protected-group member, regardless of blast radius. So it lands at Tier 2: one human approval, and a mandatory dry-run.

Tier 0 Tier 1 Tier 2 ← this plan Tier 3

Human approval / arbitration

The plan, the generated dry-run diff, and the enrichment context go to the gate as a single approval.request. A human approves, rejects, or edits the plan. Here the identity on-call analyst checks that the device on the last good sign-in belongs to the user, sees that the change is limited to two attributes, and approves.

If a second plan existed for this same incident — say a competing proposal to disable the account pending investigation — this stage would become arbitration: both plans go to the gate side by side as a Tier 3 request and the human picks one. Same gate, different question.

Execute

The orchestrator releases the approved plan to the identity agent as an execute message. The agent applies exactly the approved steps — no more — against the nearest writable domain controller, and returns a result.

"type": "result",
"ticket_id": "INC0104729",
"causation_id": "<the execute message>",
"from": "agent.identity",
"payload": {
  "plan_id": "PLAN-3",
  "target": "CORP-DC-03",
  "applied": ["unlock", "force-change-at-next-logon"],
  "status": "ok",
  "at": "2026-08-27T14:07:41Z"
}

Verify target state

Applying the change is not the finish line — the plan's own verify step runs before the ticket can close. The identity agent re-reads the account and performs a test bind. All three checks pass.

• account not locked — lockoutTime = 0
• test bind for dmorgan from the registered device certificate — succeeds
• badPwdCount = 0 — the retry loop has stopped

If any check failed, the orchestrator would run rollback R-3 (re-lock, page identity on-call) and loop back to the approval gate with the failure attached — the dashed path on the request-lifecycle diagram on the service-desk architecture page. A failed mutation is never retried without a human.

Close the ticket

The orchestrator writes the outcome back to ServiceNow and closes the Incident. The whole chain — plan, dry-run, approval, action, verification — is attached to the ticket and already in the append-only log. Elapsed wall-clock time from intake to close: 4 minutes 38 seconds, one human decision.