From Ticket to Verified Change: Working a Backlog in One Conversation

September 23, 2026 · InfraScout Team

You probably know the loop. You open a ticket, log on to a server, make the change, take a screenshot, switch back to the ticketing system, paste the screenshot, write a comment, and move the ticket along. Then you do it again for the next one. With your ticketing system connected to InfraScout, that loop collapses into one conversation: the AI reads the ticket, checks what is actually true on your servers, proposes the exact change, waits for your approval, verifies the result, and leaves the evidence in the ticket.

Below is one main scenario, two shorter variants, and the technical details worth reusing.

The setup

You need InfraScout agents on the servers the tickets are about, and your ticketing system connected as an external MCP server — for Jira and Confluence, that is an Atlassian MCP server. The AI then moves between a ticket and the host it describes without you copying anything between windows.

A starting prompt can be short:

Work on <ticket link>. Read the ticket, its parent and any linked issues.
Check the current state on the affected servers before proposing anything.
Present the exact changes you want to make and wait for my approval.
When you are done, verify the result and document it in the ticket.

Main scenario: a least-privilege service account

A colleague needs a dashboard that reports on your certificate authority. The request asks for read-only access to the CA server: no local admin rights, access over WinRM, and nothing beyond the CA's own "Read" permission.

The AI starts by loading the ticket, its parent and its linked issues, and restates the requirement in those terms. Before touching anything, it announces its plan: open a follow-up ticket, investigate, present the exact changes, and act only after you approve them explicitly.

The investigation is read-only. Using read-only PowerShell on the CA host, the AI checks which Active Directory and PKI modules are installed, whether a WinRM listener is configured, who is in the relevant local groups today, and what the CA's permission list looks like. It compares existing service accounts to learn your naming and OU conventions, and persistent memory supplies environment context from earlier sessions. It then creates the follow-up ticket, assigns it to you, and links it to the original request.

You steer, then approve

Next comes a short table of planned changes: the account to create, the local group membership to grant, and the CA permission to set, each with its target and the reason for it. The approval question offers three answers: yes, adjust, or cancel.

Suppose you choose adjust because you want a different account name. The AI checks that the new name is free in the directory, restates the full plan with the change, and asks again. Nothing happens until you say yes.

Execute, adapt, verify

Execution rarely goes exactly to plan. Creating the AD account from the CA host's agent fails, because the agent runs as the member server's own system account, which has no rights to create directory objects. The AI switches to the domain controller's agent for that step, then returns to the CA host for the group membership and the CA permission. When a cmdlet rejects its parameters, it looks up the correct syntax and retries rather than guessing.

It then verifies each change by reading it back: group membership, the account's attributes, and the CA permission list. The password is generated randomly and never printed in the chat. Finally, it comments on both tickets, updates the relevant fields, and records the change in memory so the next session knows the account exists and why.

All of this happens in one long session, over an afternoon. You skip the context switches, and the ticket ends up with better evidence than a pasted screenshot.

Variant: a scanner finding on SMBv1

A vulnerability scanner reports SMBv1 enabled on a set of servers, listed by IP address. The AI resolves each address through DNS to a host, matches the hosts to InfraScout agents, checks SMBv1 with read-only PowerShell, and saves an insight per host. Its report separates the hosts where SMBv1 is still on from the hosts it could not check because no agent runs there. It does not treat the second group as fixed.

After you approve a summarized plan, it disables SMBv1 on the affected servers, verifies the change, and comments in the ticket. If you then ask for the Windows feature to be removed as well, the AI confirms the removal is pending a reboot, reboots the servers, waits for them to return, and checks again. With a read-only monitoring MCP server connected, it can also check for alerts during the reboot window. It offers to list the alerts you should expect rather than suppress them. The whole variant takes about twenty minutes, most of it spent waiting on reboots.

Two SMBv1 settings, verified separately

Disabling the SMBv1 server setting takes effect immediately. Removing the Windows feature is a separate step that needs a reboot, and until then the feature reports DisablePending. A reboot after feature removal can take several minutes. Check both.

# Server-side protocol setting: takes effect immediately
Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol
# Windows feature: shows DisablePending until the next reboot
Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol | Select-Object FeatureName, State

Variant: re-verifying stale tickets before closing

For old findings nobody wants to close unchecked, the AI checks the live state behind each ticket: DNS records, TLS from an external test host, the firewall's NAT and policy rules through a firewall MCP server, and event searches in your SIEM. It brings you what it found, and you decide what counts as decommissioned, accepted risk, or out of scope. The AI records your decision and the evidence in each ticket before closing it.

A pentest finding turns out to be partly fixed and partly a false positive. Scanner items refer to hostnames that no longer exist in DNS. A service that is unreachable from outside traces back to a geo-restricted firewall rule, not an outage. Scanners also flag intentional design as a weakness, and gaps in audit coverage limit how much history the AI can reconstruct.

When the AI is wrong

In one finding, the AI concludes that a string in a user's AD description field is a password. You point out that it looks more like a timestamp. Instead of defending its first reading, the AI reopens the analysis. It looks at the audit events around the attribute, checks the domain's lockout threshold and any fine-grained password policies, and only then runs one controlled credential-validation test. It checks the account's bad-password count afterward. The string is not a valid password, and the finding is reclassified before the ticket closes.

Test suspected passwords carefully

Before you test whether a string is a valid password, check the lockout threshold and any fine-grained password policy that applies to the account, and check the bad-password count afterward. One careless test loop can lock out a service account.

Knowledge worth keeping

A few details from these scenarios apply well beyond them. A read-only CA dashboard needs the CA's "Read" permission, not "Issue and Manage Certificates", and the PSPKI PowerShell module can manage CA permissions. A dedicated domain service account in the local Remote Management Users group can read over WinRM without local admin rights. Creating AD objects needs domain rights, which a member server's system context does not have.

CRL, OCSP and AIA endpoints served over plain HTTP are normal practice under RFC 5280, because the signed objects protect themselves. Scanners that flag them are reporting a false positive. And AD attribute-change auditing (event 5136) only records changes from the moment it was enabled, so a missing event is not proof that nothing changed.

Where the guardrails sit

It reads before it writes and uses read-only PowerShell for reconnaissance. It asks structured approval questions that name the specific changes and targets, with yes, adjust and cancel as the answers. It limits its scope to exactly what the ticket asks for. You decide whether a ticket closes and why. When a ticket transition times out, the AI reads the ticket status again to confirm nothing was applied before it retries. At the end, the InfraScout sessions go to a reviewer like any other assessment.

Next steps

To try this with your own backlog, start by connecting your ticketing system as an external MCP server. Review tool annotations and roles to decide who can run which write tools, and read how sessions and review capture what the AI did. Persistent memory is what carries the change log into the next conversation.