Giving an AI support agent its own identity
JumpCloud’s Customer Support organization handles thousands of cases each month across a global customer base. As the team explored how AI agents could help identify patterns, accelerate support workflows, and surface potential incidents earlier, it encountered a challenge that will become increasingly familiar to organizations adopting AI agents: how do you enable agents to do useful work while giving IT and Security the visibility and control they need to govern them?
JumpCloud is using its own environment to answer that question.
As Customer 0 for Agentic IAM, the company is piloting an AI support agent with Agent Identities and AI Gateway. The goal is to give the agent a first-class identity with a named human owner, deliberately scoped application access, its own lifecycle, and activity that IT can review independently.
Rather than waiting until AI agents become commonplace across the organization, JumpCloud is testing these controls early, while the number and complexity of agents are still manageable.
We agreed to go first because this is a problem companies need to solve before they have hundreds of agents, not afterward. Using our own support agent gives us a real environment in which we can test whether ownership, access, activity, and revocation work the way IT and agent builders actually need them to.
—Justin Johnson, Senior Director, Customer Support Engineering
The Challenge: Enabling agents while keeping them governable
JumpCloud’s longer-term vision is to build a fleet of agents that can assist throughout the customer support journey: from triaging and assigning cases to triggering escalations, analyzing sentiment, reviewing cases, and helping identify incidents.
The first proof of concept is more focused: an incident agent designed to run continuously in the background and identify patterns across support cases that could indicate a product defect or broader incident.
Today, JumpCloud receives thousands of support cases each month. Historically, identifying trends across those cases has depended primarily on people recognizing patterns. More recently, the team has experimented with Claude in local environments to analyze case data.
Both approaches require manual effort and can be time-consuming or inconsistent. An agent that operates 24/7 could help the support organization identify patterns earlier.
For Justin Johnson and the Customer Support team, the priority is enabling the agent to do that work effectively. Relevant information sits across Salesforce, Intercom, Slack, Snowflake, Atlassian, and internal databases. For now, the agent has read-only access to Salesforce, Intercom, and select internal databases, but the team ultimately wants agents to take action—for example, updating cases directly in Salesforce.
That creates a separate requirement for IT and Security. As agents gain access to more systems and eventually move from reading information to taking action, Roland, JumpCloud’s VP and CISO, and his team need to know which agents exist, who owns them, what they can access, what they have done, and how to remove that access when necessary.
The challenge, therefore, is not simply making the agent capable enough to perform the use case. It is enabling the agent without creating an unmanaged identity and access layer alongside the rest of the organization.
Before Agentic IAM: Agent access was difficult to govern centrally
During earlier AI experimentation, team members connected their individual Claude accounts to tools and resources, often through MCP or native integrations. Ownership of that access varied between IT and the support organization.
That approach can work during experimentation, but it becomes harder to sustain as agents become more autonomous and operate continuously. For the teams building agents, those connections enable experimentation. For IT and Security, however, access associated with individual human accounts makes it harder to maintain a centralized inventory of agents, establish clear ownership, distinguish agent activity, and revoke access independently.
JumpCloud’s support team encountered an early example of why activity visibility also matters operationally.
During one test, a locally running agent incorrectly interpreted date formats across support cases and began analyzing cases that were out of date. The team eventually identified the problem, but without the right activity logs, it was difficult to determine exactly which information the agent had been using.
The experience reinforced a principle the support organization already follows: trust, but verify. It highlighted the importance of being able to understand an agent’s activity, both so the team building the agent can validate its conclusions and so IT and Security can maintain oversight of its access and behavior.
Why JumpCloud chose to go first
JumpCloud chose to pilot Agentic IAM internally before agent use grows significantly in scale and complexity.
The objective is not to respond to a crisis. It is to test the operating model against a real agent while the product can still adapt quickly to operational feedback.
For Customer Support, that means determining how far agents can safely progress from identifying information to taking action across business systems.
For IT and Security, it means determining whether agents can be managed centrally alongside the organization’s other identities: with clear inventory and ownership, deliberately scoped access, complete activity records, and the ability to revoke access independently.
At the heart of the pilot are two complementary questions:
- Can the agent do the job the business needs it to do?
- And can IT govern that agent throughout its lifecycle?
Answering both is important before the organization moves from one or two experimental agents to a broader fleet.
How the pilot works
The pilot follows a defined identity and access lifecycle.
Customer Support defines the agent’s purpose and the systems it needs to perform its role. IT registers the agent with its name, description, purpose, and a named human owner. For the incident agent, that owner is Justin Johnson, Senior Director, Customer Support Engineering.
Workload authentication allows the agent to prove its identity. IT can then place the agent into an Agent Group, and assign approved applications based on what the agent needs to do.
Through AI Gateway, IT can govern the agent’s connections to approved applications, review its activity, remove individual application connections, or disable the agent without disabling its human owner. This separation of responsibilities is central to the pilot.
Today, the incident agent is operating in a local environment while the team completes its AWS Bedrock build. Once that build is complete, Agent Group enrollment and connection through AI Gateway are the next stages of the pilot.
What this looks like in a support workflow
The incident agent is designed to continuously examine support data and identify patterns that humans may not immediately see across thousands of individual cases.
In the intended workflow, the agent analyzes approved support data sources and looks for signals that multiple cases may be connected. When it identifies a potential trend, it follows an established standard operating procedure and escalates the finding into Slack.
That escalation triggers a human-in-the-loop handoff. Senior support leaders and engineers review the finding, determine whether the pattern represents a genuine issue, and, when appropriate, initiate the formal engineering escalation process.
For both Support and IT, visibility into the agent’s activity is important. The team needs to understand which resources the agent accessed, when it accessed them, and what actions it took. Because support cases can change in real time, that context helps the Support team validate the agent’s findings while giving IT and Security oversight of its access and activity.
What JumpCloud hopes to prove
The support organization hopes its broader agent strategy can contribute to outcomes including:
Faster time to resolution.
Improved customer satisfaction
Faster mean time to detection for incidents
Better quality review and coaching
Fewer incident- and bug-related support cases
Those are longer-term goals for the broader support-agent strategy. For the Agentic IAM Customer Zero pilot, the question is more immediate: can JumpCloud establish an operating model in which one team can build and expand an agent’s capabilities while another can reliably govern its identity and access?
For Customer Support, success means being able to safely expand what the incident agent can do over time.
And for IT and Security, it means maintaining a centralized inventory of agents and their owners, controlling application access, having sufficient audit visibility into agent activity, and being able to revoke that access when necessary.
The pilot also gives both teams an opportunity to identify where the product may need to evolve, including onboarding effort, integration coverage, authentication reliability, gateway performance, audit completeness, and the need for more granular policy or approval controls.
What’s next
The incident agent is the first support use case in this pilot, but JumpCloud’s support organization ultimately envisions a broader fleet of agents assisting across the customer journey.
For now, the priority is to prove that the fundamentals work with one real agent in a real operating environment—and use what JumpCloud learns from that experience to strengthen Agentic IAM as adoption expands.
We’re excited to build something that addresses a shared challenge across IT and customer support. If we can build agents that deliver faster answers to customers, spot trends before they become incidents, and make life easier for our teams—all within a safe and trusted environment—then we have achieved something truly special.
—Edward Sutter, Staff Product Manager, JumpCloud
Want to learn more about the capabilities powering this pilot? Read the full JumpCloud Agentic IAM Feature Brief.