Connect
This week, something important happened in AI. Vercel, OpenAI, AWS, Microsoft, Cursor, and GitHub agreed on Agent Plugins, an open, vendor-neutral standard for packaging the tools and skills an AI agent carries with it. Build a plugin once, and it works across ChatGPT, Copilot, Cursor, VS Code, and any other client that adopts the spec.
Most of the coverage has framed this as a developer convenience story: build once, run anywhere. That’s true, and it matters. But if you run IT for an organization, the real headline is buried a layer deeper.
When agent capabilities become portable and standardized, agents stop being an experiment. They become a permanent class of actors in your environment.
An agent with tools authenticates to your systems. It holds permissions. It reads data. And, increasingly, it changes things. It’s not a chatbot. It’s a new class of user. And the moment a new class of user shows up in your organization, one question should be reflexive for any IT leader: who governs what it can do?
To be clear, the Agent Plugins standard was never meant to answer that question, and that’s to its credit. Its authors have kept the spec intentionally small: it solves packaging and portability, and it solves these problems well.
Trust, permissions, and identity belong to a different layer of the stack. Keeping these pieces outside of the v1 packaging spec is the kind of discipline that makes standards succeed. This is how good infrastructure has always been built. TCP/IP moved the packets and left encryption to TLS. SAML made identity assertions portable and left device trust to another layer entirely.
That layering is the point. Every time a portability standard lands, it’s the starting gun for the layer above it. Agents can now carry their capabilities anywhere. This means the question of governing those capabilities just went from theoretical to urgent, everywhere at once. Anyone who lived through the early days of SaaS sprawl or BYOD knows how this story goes if IT waits to get ahead of it.
We’re getting ahead of it.
The JumpCloud MCP Server
Today, the JumpCloud MCP Server is available packaged in the new Agent Plugin format.
If you’re already using our MCP server, nothing changes about what it does. This makes it portable. The same governed connection to your JumpCloud organization can now travel with you across any client that supports the standard: installed once, in one common format.
If you haven’t used it yet, the JumpCloud MCP Server connects AI agents to your admin console with over 100 tools spanning the surface of IT work: users, devices, groups, applications, SaaS license management, patch status, policies, commands, and Directory Insights™. Not just simple questions and answers.
It drives real work:
- An employee resigns. In one conversation, your agent suspends the account, revokes application access, pulls group memberships for review, and locks the laptop. A task that normally means 20 minutes across half a dozen console tabs now happens in seconds, without digging through tools.
- A suspicious login shows up in Directory Insights. You investigate it, reset the user’s password and MFA, and lock the device. This all happens in the same thread, without switching contexts while the clock runs.
- It’s Friday afternoon and a critical patch just dropped. Your agent finds every device that’s missing it and runs the remediation command against the group.
The Three Components of Agent Identity Discipline
Giving an agent write access to your directory and your device fleet should make you pause. It made us pause. That pause is where the design came from, and it’s why we think this launch is about more than a plugin.
We’ve been running this in production long enough to have a point of view that breaks into three principles. This is what we think of as the beginnings of identity discipline for agents:
- Agents act as someone. The JumpCloud MCP Server doesn’t mint a new, mysterious service identity with its own privileges. The agent inherits the exact permissions of the administrator who connected it. Nothing more. If you can’t do it in the console, your agent can’t do it either. No shadow accounts, no privilege drift.
- Agent access is a session, not a secret. Connections are established over OAuth, expire on schedules your organization controls, appear in the Admin Portal alongside everything else, and can be revoked instantly. An agent’s access should never be an API key forgotten in a config file. It should be something you can see, and something you can end.
- Agent actions are evidence. Every operation an agent performs through the MCP server lands in Directory Insights as an auditable event, attributable and queryable. There’s a satisfying recursion here. Because the agent can query Directory Insights, you can ask your agent to show you exactly what agents did in your environment this week.
None of this is a roadmap slide. It’s how the server already works, and it’s why packaging it for the Agent Plugins standard took us a day rather than a quarter. The hard part was already done.
Where This Goes
The industry is converging fast on the idea that agents need identity. You’ll hear it called agentic IAM, non-human identity, agentic identity governance. Large enterprise vendors are sketching ambitious architectures for it, and some of that work will matter.
But if you’re leading the IT team at a growing company, or the MSP behind fifty of them, you don’t need agent identity as a vision. You need it as a practice: agents that act as someone, through sessions you control, leaving evidence you can audit. That’s available today, and as of this week, it’s portable to wherever your agents live.
The Agent Plugins standard did its job. Agents can now carry their tools anywhere. The next layer of the stack, governing what those tools can do from an identity perspective, is the one we’ve always worked on. We think it’s about to become one of the most important problems in IT.
Get started with the JumpCloud MCP Server, or grab the Agent Plugin.
