Governed Agentic AI for ITSM — A Practical Blueprint

Citation

If you use this blueprint in your work or research, please cite:

Prilepskiy, D. (2026). Governed Agentic AI for ITSM — A Practical Blueprint (v0.3.0). Zenodo. https://doi.org/10.5281/zenodo.20256777

BibTeX:

@software{prilepskiy_2026_governed_agentic_itsm,
  author    = {Prilepskiy, Denis},
  title     = {Governed Agentic AI for ITSM — A Practical Blueprint},
  year      = {2026},
  publisher = {Zenodo},
  version   = {v0.3.0},
  doi       = {10.5281/zenodo.20256777},
  url       = {https://github.com/denis-prilepskiy/governed-agentic-itsm-blueprint}
}

Start with the control plane, not the agent.
The agent is the easy part.

Status: v0.3 — reference blueprint / starter kit. This is a working collection of schemas, policies, diagrams, and examples. It is not a runnable demo stack or production-ready framework. See What this repo is / is not.

A vendor-neutral reference architecture and ready-to-use engineering artefacts for shipping governed agentic AI in IT Service Management — without joining the 40% of agentic AI projects Gartner predicts will be cancelled by 2027.

Who this is for

• ITSM architects and leads designing agentic automation programmes
• Platform engineers building tool contracts and policy gates for AI agents
• Engineering managers evaluating governance requirements before enabling autonomous remediation

If you're looking for a vendor-specific implementation guide (ServiceNow, JSM, BMC), this isn't it — but the artefacts here work with any of those platforms.

What this repo is / is not

What's inside

Architecture overview

flowchart TB
  subgraph DP[Data plane]
    TRIAGE[Triage Agent] --> DIAG[Diagnostics Agent] --> PLAN[Remediation Planner]
    PLAN --> RUN[Tool Runner] --> MCP[MCP Tool Servers] --> SYS[Enterprise Systems]
    SYS --> VAL[Validation] -->|pass| CLOSE[Resolve]
    VAL -->|fail| ROLL[Rollback]
  end

  subgraph CP[Control plane]
    POL[Policy Engine] --> APP[Human Approval]
    POL --> AUD[Audit Log]
    POL --> EVAL[Eval Harness]
  end

  PLAN --> POL
  POL -->|allow| RUN

  style CP fill:#e8f0fe,stroke:#2e75b6
  style DP fill:#f5f5f5,stroke:#999

Full Mermaid diagrams with complete detail are in diagrams/. GitHub renders .mermaid files natively.

Quick start

1. Review the workflow declaration

examples/workflow.yaml defines autonomy boundaries for a starter scope (certificate expiry, service restart, DNS misconfiguration). Adapt scope.services and scope.allowed_categories to your environment.

2. Define your tool contracts

Use schemas/tool-restart-service.json as a template. For each tool your agents can invoke:

• Define typed input_schema and output_schema
• Add safety metadata: idempotent, supports_dry_run, max_calls_per_incident, rollback_tool
• Set dry_run: true as the default
• Record the contract version you executed against in pre_execution.tool_contract_versions

The repo includes 8 tool contracts covering the most common ITSM operations. Use schemas/tool-schema-template.json to add your own.

3. Test policies against sample incidents

# Install OPA (https://www.openpolicyagent.org/docs/latest/#running-opa)
# macOS:
brew install opa
# Linux:
curl -L -o opa https://openpolicyagent.org/downloads/v1.4.2/opa_linux_amd64_static
chmod 755 opa && sudo mv opa /usr/local/bin/

# Test: low-risk incident (should auto-approve)
opa eval \
  --data policies/ \
  --input examples/test-incidents/low-risk-cert-expiry.json \
  "data.itsm.guardrails.decision"

# Test: medium-risk incident (should require approval)
opa eval \
  --data policies/ \
  --input examples/test-incidents/medium-risk-multi-service.json \
  "data.itsm.guardrails.decision"

# Test: high-risk incident (should require approval — contains "rollback_deployment" tool)
opa eval \
  --data policies/ \
  --input examples/test-incidents/high-risk-deploy.json \
  "data.itsm.guardrails.decision"

4. Calibrate thresholds with offline replay

Before enabling execution in production:

1. Collect 2–4 weeks of historical incidents for your target categories
2. Run each through the policy engine with the artefacts in this repo
3. Measure: approval rate, false-approval rate, missed-automation rate
4. Adjust risk_score thresholds and allowlists based on the data

5. Instrument with OpenTelemetry

Propagate traceparent through every tool call (the tool contracts include a traceparent field for this). Emit stage-level metrics: triage_duration, policy_decision, tool_execution_time, validation_result, rollback_count.

Policy pack

The policies/ directory contains a main guardrails policy and 8 focused modules:

Decision vocabulary

The policy pack emits three verdicts. They map onto the vocabulary used in the accompanying article and architecture diagrams as follows:

Every admitting verdict carries obligations in constraints: call limits, dry-run and validation requirements, the evidence fields that must be persisted first, whether approval binds to the plan hash, and the fallback path on timeout.

Context freshness

Freshness is enforced as an admission criterion, not surfaced as a warning. Thresholds live in the workflow declaration:

guardrails:
  context_freshness:
    cmdb_max_age_seconds: 300
    metrics_max_age_seconds: 60
    on_stale_context: "deny_and_escalate"

Ages are computed against context.evaluated_at — the moment of policy admission — rather than wall-clock time, so test fixtures remain reproducible indefinitely. Incidents that declare no context timestamps produce no violation, so the module is backwards compatible.

examples/test-incidents/stale-context-restart.json exercises this: every other signal is benign — low risk score, single declared service, allowed category, inside the change window — and only the freshness gate denies it.

# Test: stale context (should deny, with the freshness gate named in the reasons)
opa eval \
  --data policies/ \
  --input examples/test-incidents/stale-context-restart.json \
  "data.itsm.guardrails.decision"

Freshness enforcement requires the full policy pack (--data policies/). It is not part of the standalone fallback logic in guardrails.rego.

Governance mapping

See MATURITY.md for how governance requirements scale with autonomy level.

Repo structure

governed-agentic-itsm-blueprint/
├── README.md
├── MATURITY.md
├── CONTRIBUTING.md
├── SECURITY.md
├── CHANGELOG.md
├── LICENSE                         (Apache 2.0)
├── .gitignore
├── .github/
│   ├── workflows/
│   │   └── validate.yml            (CI: JSON + YAML + Rego validation)
│   └── ISSUE_TEMPLATE/
│       └── adaptation-report.md
├── diagrams/
│   ├── reference-architecture.mermaid
│   ├── auto-remediation-pipeline.mermaid
│   └── governance-layers.mermaid
├── schemas/
│   ├── evidence-bundle.schema.json
│   ├── policy-decision.schema.json
│   ├── validation-result.schema.json
│   ├── tool-restart-service.json
│   ├── tool-restart-service-rollback.json
│   ├── tool-validate-health.json
│   ├── tool-renew-certificate.json
│   ├── tool-drain-connections.json
│   ├── tool-rollback-deployment.json
│   ├── tool-notify-stakeholders.json
│   ├── tool-open-change-record.json
│   └── tool-schema-template.json
├── policies/
│   ├── guardrails.rego
│   ├── deny_prohibited_tools.rego
│   ├── require_approval_by_risk.rego
│   ├── require_approval_by_blast_radius.rego
│   ├── enforce_dry_run.rego
│   ├── enforce_change_window.rego
│   ├── enforce_environment_exclusions.rego
│   ├── enforce_tool_call_budget.rego
│   └── enforce_context_freshness.rego
└── examples/
    ├── workflow.yaml
    ├── change-risk-prompt.md
    ├── evidence/
    │   ├── example-evidence-bundle.json
    │   └── example-evidence-bundle-approval.json
    └── test-incidents/
        ├── low-risk-cert-expiry.json
        ├── low-risk-cert-expiry.execution.json
        ├── medium-risk-multi-service.json
        ├── high-risk-deploy.json
        └── stale-context-restart.json

Contributing

See CONTRIBUTING.md for guidelines. The most valuable contributions are adaptation reports — real-world feedback on what worked and what didn't.

Related work

• Model Context Protocol (MCP) Specification
• Agent2Agent Protocol (A2A)
• Open Policy Agent (OPA)
• OpenTelemetry
• ISO/IEC 42001 Explained
• NIST AI RMF 1.0
• EU AI Act — Entry into force

License

Apache 2.0 — see LICENSE.

Author: Denis Prilepskiy — Agentic AI architect specialising in production-grade multi-agent systems for regulated industries. Senior Enterprise Architect at NTT Data (London). Published in HackerNoon (Top Story) and MIPT Digital (Habr), with IEEE and HBR submissions under review. HackerNoon @denisp · LinkedIn