Beyond Tickets: The Architecture Agentic ITSM Needs for SecOps

Part 2 of the series From Security Signal to Governed Action

There is a tempting way to think about AI in IT service management:

Take the existing ITSM platform, add an LLM, expose a few APIs, and let a copilot summarize tickets, generate knowledge articles and answer questions.

Those capabilities are useful.

But they are not enough for the intersection of ITSM and security operations.

SecOps presents a harder problem. The platform must interpret signals arriving from many systems, understand changing relationships across the enterprise, reason about both cyber risk and operational risk, coordinate actions across multiple tools, respect approval and segregation-of-duty requirements, verify the result and preserve the evidence.

That requires a different architecture.

The simplest way to describe it is:

Signal → Graph → Agents → Governance → Action → Verification

Or, viewed as an enterprise stack:

Security systems → Dynamic context graph → Agent plane → Agentic ITSM and change → Execution platforms → Security verification

This is not a replacement for the security stack. It is the operational layer that connects detection to governed action.

Why bolting AI onto tickets is not enough

Traditional ITSM platforms were designed primarily around records and deterministic workflows.

A condition occurs. A record is created. Fields are populated. Rules determine routing. People complete tasks. Approvals move the process forward.

That architecture remains valuable for control and accountability, but security decisions increasingly require something more dynamic.

Imagine a newly disclosed vulnerability appears on several hundred assets.

A static workflow can say:

If CVSS is greater than 9, assign P1.

A reasoning system should be able to ask:

• Is the vulnerability being actively exploited?
• Is it in CISA's Known Exploited Vulnerabilities catalog?
• What is its current exploit-likelihood signal?
• Which affected systems are internet-facing?
• Which support critical services?
• Are vulnerable components actually enabled?
• What identities have privileged access to those systems?
• Do compensating controls reduce exposure?
• Is there a recent incident associated with the same assets?
• Is a remediation already planned?
• What dependencies make an emergency patch dangerous?

CISA describes its KEV catalog as the authoritative source of vulnerabilities known to have been exploited in the wild and recommends it as an input to vulnerability-management prioritization.[1] FIRST's Exploit Prediction Scoring System, meanwhile, estimates the probability that a published CVE will be exploited in the wild in the next 30 days.[2]

Those signals become far more useful when combined with enterprise context.

That is why the first architectural requirement is not the LLM.

It is the graph.

Layer 1: A dynamic enterprise context graph

A traditional CMDB is typically modeled around configuration items, attributes and relationships.

The problem is not that the CMDB is obsolete. The problem is that SecOps needs a richer and more current contextual model than a periodically maintained configuration inventory can usually provide on its own.

Think of the context required for a security decision:

Asset → software → vulnerability → identity → owner → application → business service → dependency → internet exposure → control → incident → change

Each element may come from a different authoritative system.

The dynamic context graph should connect them.

That graph may include:

• CMDB configuration items and service maps
• asset inventories
• endpoint posture
• installed software
• cloud resources
• identity and privilege relationships
• vulnerability findings
• security controls
• ownership data
• application dependencies
• business criticality
• open incidents and problems
• active and historical changes
• employee and device relationships

The important word is dynamic.

For agentic operations, context cannot simply be a snapshot assembled during an annual CMDB cleanup. It has to reflect what the enterprise knows now, with provenance back to its source systems.

Why the graph changes the decision

Consider the same critical CVE appearing on two machines.

System A is an isolated development server with no external exposure and a compensating control.

System B is an internet-facing authentication server supporting a revenue-critical application, with evidence that the affected software is reachable and no compensating control.

The CVE is identical.

The operational decision is not.

This is the limitation of treating vulnerability management as a simple severity-to-priority mapping.

The graph allows the enterprise to reason about relationships and consequence, not simply attributes.

It also enables much more useful questions:

Which externally exposed assets affected by this CVE support Tier-1 services and have no mitigating control?

Which critical applications depend on servers that are currently outside patch policy?

Which remediation actions would touch systems involved in a major incident or an active production change?

Which users have privileged access to affected assets?

Those are graph questions before they are AI questions.

Layer 2: The agent plane

Once the context is accessible, the next architectural layer is the agent plane.

This is the reasoning and orchestration layer that sits across IT and security systems.

An agent should be able to:

Observe → Research → Reason → Plan → Act → Verify

That sounds simple, but each step matters.

Observe

The agent receives a signal from a scanner, SIEM, EDR, identity platform, CSPM system, DEX platform or another operational source.

Research

It collects the evidence needed to understand the situation. That may include internal tools and approved external sources: CISA KEV, exploit-likelihood data, vendor advisories or threat intelligence.

Reason

It evaluates the evidence in the context of the enterprise: service importance, exposure, controls, dependencies, operational state and policy.

Plan

It proposes the next action: patch, isolate, change a configuration, revoke a privilege, defer under a documented exception, or escalate to a human.

Act

If policy authorizes the action, the agent invokes the appropriate execution system. Otherwise it creates the required approval and waits.

Verify

It returns to an authoritative source to confirm the desired security outcome actually occurred.

This is a major distinction between an agent and a workflow.

A workflow executes a predefined path.

An agent can investigate which path is appropriate — while still operating inside policy and control boundaries.

Layer 3: Agentic change management

At the SecOps intersection, the most consequential ITSM capability may be change management.

Security teams often know what should change before the enterprise knows how to change it safely.

A critical patch may be obvious from a cyber-risk perspective. Yet the affected system could sit in the middle of a complex business service, have fragile dependencies, require a specific maintenance sequence or support a process that cannot tolerate an unplanned reboot.

Traditional change management handles this by asking humans to assemble the context manually.

An agentic change process can do much of that work continuously.

For a proposed remediation, it can gather:

• affected configuration items
• dependent applications and services
• service criticality
• owners and approvers
• recent incidents
• overlapping changes
• historical success or failure of similar changes
• maintenance windows
• implementation prerequisites
• testing steps
• rollback options

It can then construct a change plan and explain the reasoning behind the proposed risk level.

The important point is not to remove change control.

It is to make change control faster, more contextual and more proportional to risk.

Governing autonomy with two dimensions of risk

One useful way to think about agentic change is to evaluate two dimensions simultaneously:

1. Cyber risk — how dangerous is it to wait?
2. Change risk — how dangerous is it to act?

That creates four broad operating modes.

This is not a universal policy matrix. Every enterprise will set its own thresholds, authorities and exceptions.

But the concept is important:

The level of autonomy should be proportional to both the risk of inaction and the risk of change.

That is more sophisticated than either extreme — “AI can never change production” or “AI should automatically fix everything.”

Layer 4: Policy as the control plane

Agents should not decide their own authority.

Enterprise policy should.

A policy layer can define:

• which actions an agent may execute automatically
• which environments may be changed
• risk thresholds
• required approvals
• emergency change procedures
• maintenance windows
• segregation-of-duty requirements
• rollback requirements
• communication requirements
• evidence-retention requirements
• escalation conditions

This creates an essential separation:

AI provides intelligence. Policy defines authority.

That separation is one of the architectural foundations for responsible enterprise autonomy.

It also makes agent behavior easier to audit. Instead of asking, “Why did the AI do that?” the enterprise can answer two separate questions:

1. What did the agent conclude, and what evidence supported the conclusion?
2. What policy granted or denied the authority to act?

That distinction matters.

Layer 5: The execution fabric

Reasoning is not remediation.

At some point, something has to change in the real environment.

The execution layer may include:

• endpoint management platforms
• DEX and RMM systems
• configuration-management tools
• cloud APIs
• identity and PAM systems
• EDR/XDR response actions
• orchestration platforms
• scripts and runbooks
• application deployment systems

The agentic ITSM layer does not need to replace these tools.

It needs to know which tool is authoritative for which action, invoke it under policy, monitor the execution and preserve the result.

This is why the phrase “agentic orchestration” can be more useful than “AI automation.”

The enterprise already has many automation tools. The missing capability is often the intelligence that decides when and how to coordinate them.

Layer 6: Closed-loop verification

Security remediation is complete only when the risk has been independently verified.

NIST's enterprise patch-management guidance explicitly includes verification as part of the patch-management lifecycle.[3]

That principle should extend beyond patching.

If a vulnerability scanner generated the finding, go back to the scanner.

If an endpoint control generated the posture issue, re-check the endpoint.

If an identity platform identified excessive privilege, verify that the entitlement is actually removed.

If a security configuration was changed, test the control state again.

The loop becomes:

Detect → Understand → Decide → Change → Execute → Verify

And when verification fails:

Reopen → Diagnose → Adjust → Execute again

This is what makes the system outcome-oriented rather than task-oriented.

A successful API call is not a security outcome.

Layer 7: Continuous evidence

Every part of this process should produce evidence automatically.

The system should be able to reconstruct:

• the original security signal
• the enterprise context at the time
• the external intelligence consulted
• the agent's reasoning and recommendation
• the policy applied
• the human approvals, if any
• the commands or actions executed
• the systems affected
• any exceptions or failures
• the verification result
• the final closure decision

This changes audit from an after-the-fact collection exercise into a property of the operational system.

It also improves explainability.

An enterprise should not merely know that an agent assigned a vulnerability P1. It should be able to see why:

Known exploitation + external exposure + critical service + no mitigating control + privileged access path.

And if a technically severe vulnerability was not treated as an emergency, the record should show the countervailing evidence and the policy that permitted the decision.

The architecture in one view

The complete model can be summarized as seven layers:

1. Security signals

Qualys, Tenable, Defender, EDR/XDR, SIEM, identity, CSPM and other authoritative systems identify conditions.

2. Dynamic enterprise graph

Assets, services, software, identities, dependencies, vulnerabilities, exposures, owners and controls are connected into usable context.

3. Agent plane

Agents investigate, research, reason, prioritize and plan.

4. Agentic ITSM and change

Incidents, problems, changes, approvals, SLAs and ownership provide operational governance.

5. Policy control

The enterprise defines autonomy, approval, risk and segregation-of-duty boundaries.

6. Execution fabric

DEX, RMM, endpoint management, cloud, IAM/PAM, EDR and automation tools make the approved change.

7. Verification and evidence

The originating systems confirm the outcome, and the platform preserves the full decision and execution trail.

The result is not an AI feature added to a ticketing platform.

It is a governed agentic operating system for action across IT and SecOps.

The role of humans changes — it does not disappear

Agentic architecture should reduce human coordination work, not eliminate human accountability.

People remain essential where judgment, accountability, business tradeoffs or exceptional risk require them.

What should disappear are avoidable tasks such as:

• manually copying scanner data into a ticket
• searching five systems to find an owner
• reconstructing service dependencies
• rewriting standard implementation plans
• chasing routine approvals
• checking whether a patch job finished
• reopening a ticket days later because the vulnerability remained
• assembling audit evidence from email and spreadsheets

The human should increasingly be asked to make the important decision, not perform the clerical work required to prepare for it.

Why this matters beyond security

Although SecOps makes the requirement urgent, the architecture has implications across IT operations.

The same context graph, agent plane, policy system and closed-loop execution model can support:

• major incident management
• service reliability
• asset lifecycle
• software compliance
• employee experience
• identity operations
• cost optimization
• configuration governance

SecOps is a demanding proving ground because the cost of delay is visible and the control requirements are high.

If agentic ITSM can reason and act safely here, the same architecture can transform much more of enterprise operations.

The future of ITSM is therefore not a better ticket interface.

It is the ability to turn a signal into contextual, explainable and governed action — at the speed the modern enterprise now requires.

---

Coming next

Part 3: Vulnerability Management Is Just the Beginning — Six SecOps Workflows Agentic ITSM Can Transform

We will apply this architecture to concrete operational journeys: vulnerability remediation, security incidents, privileged access, configuration risk, endpoints and continuous compliance.

Reload preview

Sources and further reading

1. CISA, Known Exploited Vulnerabilities Catalog. https://www.cisa.gov/known-exploited-vulnerabilities-catalog
2. FIRST, Exploit Prediction Scoring System (EPSS). https://www.first.org/epss/
3. NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology. https://csrc.nist.gov/pubs/sp/800/40/r4/final