How to Govern AI Agents in Jira, ServiceNow, and ITSM Workflows

Why Standard ITSM Permission Models Do Not Fit AI Agents

ServiceNow and Jira were built around role-based access control and static service accounts designed for predictable human behavior or fixed integration logic. An AI agent making dynamic, context-dependent tool calls does not map cleanly onto these models. ServiceNow's OAuth-based integration approach typically issues scoped access tokens at the application level, not per-agent or per-action, unless an organization explicitly configures fine-grained ACLs. Atlassian's Forge and Connect frameworks follow a similar pattern: API scopes are granted at app installation, meaning an AI agent built as an Atlassian app inherits broad workspace-level permissions unless a developer manually scopes them down. In both platforms, the default posture favors breadth of access over precision, which is workable for a fixed integration but becomes a liability for an agent whose behavior varies based on model output, retrieved context, or chained tool calls.

Vendor Responses: ServiceNow AI Agent Types and Atlassian Rovo

Both major ITSM vendors have begun addressing this gap, though with different approaches. ServiceNow has introduced an AI Agent Orchestrator along with a distinct "AI Agent" user type, separate from standard human accounts, intended to support agent registries and permission scoping across multiple agents operating in workflows. This is a meaningful step toward per-agent identity, though public documentation does not detail the exact granularity of runtime policy controls available. Atlassian's Rovo, by contrast, operates using Atlassian's existing permission model and app access scopes by default rather than introducing a separate agent-specific identity. That means Rovo-based agents inherit the same installation-level scopes as any other Forge or Connect app unless explicitly constrained. Platform engineering teams should treat these as starting points, not complete governance solutions, since neither vendor has published evidence of pre-execution, per-tool-call policy evaluation as a native capability.

Where to Insert Runtime Policy Enforcement

The practical fix for both platforms is the same: insert a policy enforcement point between the agent and the ITSM APIs or tool servers it calls, rather than relying on OAuth scopes set once at integration time. Model Context Protocol (MCP), released by Anthropic in November 2024, defines a client-server architecture for connecting agents to external tools and explicitly leaves authorization and access control to the hosting application or gateway layer. This is a design choice, not an oversight, and it creates a natural interception point. A gateway sitting in front of an MCP tool server, or in front of direct Jira/ServiceNow API calls, can evaluate each tool call against policy before it executes, rather than only reviewing what happened after the fact in an audit log.

Implementation Steps for Platform Engineering Teams

Rolling out governance for ITSM agents is incremental work, not a single configuration change.

Audit Trails and the Human vs. Agent Attribution Problem

Both Jira and ServiceNow record actions under the authenticated identity that executed them, whether that is a human user, a service account, or an API token. Without a distinct agent identity type, an agent's actions are often indistinguishable from a generic integration or a human operator in the audit trail. This creates a direct conflict with accountability expectations described in NIST's AI Risk Management Framework, which frames governance, mapping, measuring, and managing as continuous functions requiring clear attribution. CISA and NSA guidance published in 2025 reinforces this, recommending identity attribution and access logging specifically for autonomous or semi-autonomous AI components operating in enterprise IT environments. For platform teams, the practical requirement is that audit logs capture agent identity, the specific tool or action invoked, the parameters used, and the policy decision outcome as a separate, queryable record, not folded into generic API logs.

Tradeoffs: Latency, Compliance, and Change Management

Runtime enforcement is not free. Intercepting and evaluating every tool call introduces latency, which matters for time-sensitive automations like incident triage where SLA windows are tight. Teams should account for this when designing interception points, potentially applying lighter-weight checks to low-risk actions and more thorough evaluation to high-impact ones. There is also a governance dimension specific to ITSM: ServiceNow's Change Enablement and similar Jira workflows assume a human actor initiates or approves changes. Introducing agents into these flows requires explicit policy decisions about whether an agent can initiate a change, approve one, or only recommend one for human sign-off. This is a policy question as much as a technical one, and it should be resolved before agents are granted access to change or CMDB write actions, not discovered after deployment.