How should security teams govern AI agent self-service in ITSM?

Treat the agent as part of the control plane, not a support shortcut. Define an approved-action list, bind every action to a named owner, and require explicit exception handling for anything outside routine fulfilment. That gives service-management automation a governance boundary that IAM and PAM teams can audit and review.

Why This Matters for Security Teams

AI agent self-service in ITSM is attractive because it reduces queue pressure, but it also turns a ticketing workflow into an execution channel. Once an agent can reset access, provision software, or trigger workflow approvals, the question is no longer convenience. It becomes whether the agent is operating inside an auditable control boundary. Guidance from the OWASP Agentic AI Top 10 and NIST’s NIST AI Risk Management Framework both point to the same problem: autonomous action requires runtime governance, not just preapproved workflow design.

NHI Management Group has highlighted how quickly agent behaviour can move beyond intended scope, with AI Agents: The New Attack Surface reporting that 80% of organisations have already seen agents act outside their intended scope. That is especially relevant in ITSM, where the same identity may be trusted across multiple queues, tools, and approval paths. If the agent can chain actions through catalog items, knowledge articles, and integrations, a small misconfiguration can become broad operational exposure. In practice, many security teams discover this only after an over-permissioned automation has already executed a high-impact request, rather than through intentional design reviews.

How It Works in Practice

Governance starts by treating the agent as a workload identity with narrowly scoped entitlements, not as a generic service account. The strongest pattern is to combine approved actions, context-aware authorization, and short-lived credentials so the agent can only perform the exact task requested. That means each ITSM action should be tied to an explicit business purpose, a named owner, and a policy decision that is evaluated at request time, not buried in static role assignment.

In practice, teams usually split self-service into three layers:

• Approved catalog actions such as password resets, account unlocks, or status lookups.
• Conditional actions that require runtime checks, such as device posture, ticket classification, or user risk level.
• Exception paths that force human approval when the request crosses data sensitivity, privilege, or financial thresholds.

This is where static IAM often fails. A role can say what the agent may do, but it cannot reliably describe when the action is safe. For autonomous workflows, current guidance suggests intent-based authorization, ephemeral credentials, and policy-as-code evaluation using systems such as CSA MAESTRO agentic AI threat modeling framework. The operational goal is to make every request traceable to a policy decision, every action attributable to a human owner, and every secret short-lived enough to reduce blast radius. NHIMG’s Top 10 NHI Issues and the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs both reinforce that lifecycle control and revocation are not optional when identities can act on their own. These controls tend to break down when ITSM platforms allow agents to invoke nested automations across multiple tools because the effective privilege chain becomes hard to predict and harder to revoke quickly.

Common Variations and Edge Cases

Tighter self-service controls often increase operational overhead, requiring organisations to balance faster fulfilment against tighter exception handling. That tradeoff is real in high-volume service desks, where teams may want the agent to resolve common requests without human touch. Best practice is evolving, but there is no universal standard for how much autonomy is acceptable for every ticket class. The safest approach is to allow the lowest-risk actions to remain fully automated while requiring step-up review for anything that touches privileged access, sensitive data, or cross-system change.

Edge cases show up when the agent interacts with multiple identities at once, such as approving a workflow for one user while querying another user’s asset or access record. They also appear when a request seems routine but the downstream integration is not. For example, a simple password reset can become high risk if the same workflow can also issue a new token, rotate a secret, or update recovery channels. NIST’s framework and the Ultimate Guide to NHIs — Regulatory and Audit Perspectives both support strong logging, ownership, and reviewability, but the exact control set will vary by environment.

Security teams should assume the agent will eventually encounter ambiguous requests, stale data, and conflicting approvals. That is why policy exceptions, revocation paths, and audit evidence need to be built into the workflow rather than added later. In more fragmented environments, especially where ITSM, IAM, and endpoint tools are run by separate teams, governance often fails because no single group can see the full action chain.

Related resources from NHI Mgmt Group

• How should security teams govern API keys used for generative AI access?
• How should security teams govern Active Directory service accounts?
• How should security teams govern service principals in Entra ID?
• How should security teams govern Microsoft-driven service workflows across Teams, Intune, and Entra?