Agent Governance

Governance requirements for agentic ITSM programs: access control, audit, accountability, and human-in-the-loop design

Agent governance is a foundational requirement for an agentic ITSM program, not an optional enhancement. Agents that operate without defined access controls, audit trails, action boundaries, and human override mechanisms are uncontrolled systems running in a production environment.

The consequences of uncontrolled agent operation compound quickly. Agents work at machine speed. An agent making incorrect decisions on a process that handles 500 tickets per day can cause 500 incidents per day before anyone notices. Governance is the mechanism that prevents that scenario and provides the accountability structure to diagnose and correct it when agent performance degrades.

This governance model is deliberately lightweight in its current form. It defines the minimum requirements that every agentic ITSM deployment should satisfy. As the framework matures, as the community develops deployment experience, and as regulatory expectations around AI governance become more specific, this model will be expanded and formalized. That evolution will happen through the community contribution process described in the Participation Guide.

Governance Architecture Overview

Requirement 1: Agent Identity Management

Every agent operating in a production ITSM environment must have a distinct, named identity within every system it accesses. That identity must be:

Separate from human identities. Agent accounts must be distinguishable from human user accounts. The purpose is auditability: every action an agent takes must be attributable to that specific agent, not to a shared service account that humans also use. Shared accounts make it impossible to determine whether an action was taken by an agent or a human, which makes the audit trail functionally useless.

Scoped by least privilege. Agents should have access only to the systems and data required to perform their defined function. An incident resolution agent does not need write access to the financial management system. A CMDB maintenance agent does not need access to HR data. Least-privilege scoping limits the blast radius when agents make mistakes, because a mistake in a scoped environment affects only what the agent was authorized to reach.

Subject to periodic access review. Agent access should be reviewed on a defined cadence, more frequently than human access reviews given the higher change velocity of agent capability evolution. When an agent’s function changes, its access scope must be updated to reflect the new function. When an agent is retired, its access must be revoked.

Tracked in an AI asset inventory. Every agent in production must be registered in an AI asset inventory that captures: the agent’s name and identifier, its owner, its function, the systems it accesses, its access permissions, its autonomy tier, and the date of its last access review.

Requirement 2: Autonomy Tier Classification

Every agent must be classified into one of three autonomy tiers that define how it operates and what governance controls apply.

Tier 1: Assisted. The agent recommends or drafts an action; a human decides and executes. The agent may surface a resolution recommendation, draft a knowledge article, or propose a change risk assessment, but no action is taken without explicit human direction. This tier is appropriate for novel processes, high-stakes decisions, and early deployment phases where agent accuracy is not yet validated.

Tier 2: Collaborative. The agent executes defined actions within a scoped domain, with human review available before or immediately after execution. The agent acts, but the action is either reversible before taking effect or a human review step follows execution within a defined timeframe. This tier is appropriate for moderate-complexity processes where agent accuracy is validated and human oversight remains practical.

Tier 3: Autonomous. The agent executes actions within defined parameters without human review of individual actions. The agent acts, records every action in the audit log, and is subject to periodic performance review rather than per-action review. This tier is appropriate for high-volume, well-defined processes where agent accuracy is demonstrated and the blast radius of individual errors is limited and recoverable.

Tier classification is a policy decision, not a capability assessment. An agent technically capable of autonomous action should not be placed in Tier 3 until its accuracy in the specific context is validated, governance controls are functional, and the organization has confidence in its ability to detect and respond to degradation.

Requirement 3: Action Boundary Definitions

Every agent must have a current, versioned document defining its action boundaries. This document is a policy artifact, not a technical specification, and must be maintained by a named human owner.

The action boundary document defines:

What the agent may do autonomously (consistent with its autonomy tier): The specific actions the agent is authorized to take without human approval, the conditions under which those actions are appropriate, and the systems on which those actions may be performed.

What the agent must escalate for human review: The categories of action that the agent may recommend or prepare but may not execute without human approval. The escalation path must be defined: who receives the escalation, within what timeframe they must respond, and what the agent does if the escalation is not acknowledged.

What the agent may never do: Explicit prohibitions, regardless of instruction or inferred intent. This list should be short but firm. Common entries include: delete production data, modify access control configurations, execute emergency changes without human authorization, and take any action in a system not listed in the agent’s approved system scope.

Action boundary documents must be version-controlled. Changes to an agent’s boundaries require a review and approval process, documented in the governance record for that agent. When an agent’s autonomy is expanded, the expansion must be justified by performance data demonstrating accuracy in the current tier.

Requirement 4: Audit and Logging

Every action an agent takes in a production environment must be logged in a tamper-proof, searchable audit record. The minimum audit log entry for any agent action must capture:

The agent identity that took the action
The timestamp of the action (to millisecond precision)
The action taken (what was done)
The system affected
The ticket, CI, or record affected
The inputs that informed the decision (the data the agent reasoned over)
The confidence score associated with the decision, if applicable
The outcome of the action

Audit logs must be retained for a minimum period consistent with the organization’s regulatory obligations. For most enterprise ITSM environments, a minimum of 12 months is appropriate; regulated industries may require longer retention.

Audit logs must be accessible for investigation. When an incident is traced to an agent action, the full decision chain for that action must be reconstructable from the audit record. “The agent did it and we cannot explain why” is not an acceptable outcome for a governed deployment.

Requirement 5: Human-in-the-Loop Controls

Every agent must have functional human-in-the-loop controls, regardless of its autonomy tier. These controls must be tested in production, not just documented.

Confidence thresholds. Agents must be configured with confidence thresholds below which they escalate to human review rather than acting autonomously. The threshold must be calibrated against historical performance data: too high and agents escalate too much, negating the value of automation; too low and agents act on insufficient evidence, producing errors.

Override mechanisms. Humans must be able to countermand any agent action, either before it executes (for Tier 1 and Tier 2 agents) or immediately after execution (for Tier 3 agents). The override mechanism must be accessible, clearly documented, and tested regularly.

Escalation paths. Every agent must have a defined escalation path that is functional, staffed, and tested. An escalation path that routes to an unmonitored queue is not a functional escalation path. Escalation response time standards must be defined and monitored.

Kill switches. Every agent must have a mechanism that pauses or stops its operation immediately. This mechanism must be accessible to a defined set of named individuals without requiring escalation. The kill switch must be tested at deployment and re-tested after any significant change to the agent’s function.

Requirement 6: Performance Review Cadence

Agents are not static systems. Their performance changes over time as the data they reason over evolves, as the environment changes, and as edge cases accumulate. A governance model that does not include performance review will eventually produce agents operating significantly below their initial performance level without anyone noticing.

Every agent in production must be subject to a formal performance review at a defined cadence. The minimum cadence is quarterly for Tier 3 agents and semi-annually for Tier 1 and Tier 2 agents. Reviews must examine:

Performance against the five measures defined in Section 6, trended over the review period
The pattern of human overrides (the HOR measure) and the root causes of overrides
Any incidents or escalations attributable to agent error in the review period
Whether the agent’s action boundaries remain appropriate given observed performance
Whether the agent’s data dependencies have changed in ways that affect performance

Performance review findings must be documented and acted on. Agents with degrading performance must be investigated and remediated. Agents demonstrating consistent performance in their current tier are candidates for autonomy expansion, subject to the appropriate approval process.

Governance Model Status and Evolution

This governance model defines the minimum requirements for a responsibly governed agentic ITSM program. It is intentionally lightweight: it defines what must be done without prescribing the precise mechanisms through which every requirement must be satisfied, because those mechanisms vary by organizational context, regulatory environment, and ITSM platform.

The governance model will formalize as three things happen: the community develops shared deployment experience that surfaces additional requirements not captured here; regulatory expectations for AI governance in enterprise IT environments become more specific; and the framework reaches a maturity level that warrants more prescriptive guidance.

Community members with governance experience in agentic deployments are specifically invited to contribute to the evolution of this section. See the Participation Guide for how to do so.

References

Dumas, M., Milani, F., & Chapela-Campa, D. (2026). Agentic Business Process Management Systems. arXiv preprint arXiv.18833.

Gartner. (2025). Gartner Predicts Agentic AI Will Autonomously Resolve 80 Percent of Common Customer Service Issues Without Human Intervention by 2029. Gartner Newsroom.

Kore.ai. (2026). Agentic AI in ITSM: Benefits, Use Cases, and Challenges. Kore.ai Blog.

Maes, S. H. (2026). Agentic Smart ITIL, And The Disruption Of The Market Of Conventional Enterprise Applications. Stephane H. Maes’ Blog on WordPress / Multi-Agent Research Notes.