Without RBAC for Agent Skills and MCP, your entire organization basically has root access to your company

Let me paint a picture. Your company has rolled out Claude or ChatGPT as the standard AI tool. You've connected MCPs to Stripe, your HRIS, Datadog, your CRM, and Slack. A senior engineer set this up because they needed to answer hard cross-system questions and it works beautifully. Now a marketing intern sits down, opens the same LLM harness with the same MCP config, and types "show me revenue by customer for the last 12 months." They get it. They type "show me the salary bands for the engineering team." Maybe the HRIS blocks that based on their individual permissions, maybe it doesn't. But that's almost beside the point. Why does a marketing intern have an HRIS MCP connected at all? Why do they have Stripe? Why is the LLM even aware of these tools in their session?

Every MCP in that intern's context is a tool the AI will consider using, a surface that exists for no good reason, and a bet that the downstream system's permission model is airtight. For some of those systems it might be. For others you'd be surprised. The real question isn't whether the intern can successfully pull salary data, it's why we've set things up so that the attempt is even possible.

The everything application is here and it has no guardrails

We are in the middle of a tectonic shift in the application layer. Give an LLM harness a set of MCPs and targeted Agent Skills and you have an "everything application," the LLM acting as a universal interface layer across all of your company's systems and data. Connect it to your Stripe data, your Datadog, and your CRM and you can answer questions like "Show me the month-to-month customers that spend the most but use the least." Add an MCP for something like Granola and you can follow up with "What has that customer expressed interest in that might increase usage?" Layer in Skills, shareable workflows that tell the LLM how to coordinate those tools, and you get exactly what you're looking for.

What used to require a custom report or yet another SaaS tool to weave sources together is now just a prompt. Companies that don't adopt this will be outclassed by those that do. But the thing that keeps getting glossed over is that the everything application is also the everything exposure when you don't control who can access what.

A gap in how the ecosystem was designed, not an oversight being fixed

The MCP ecosystem grew out of developer tooling and open source, where single-player is the default. The protocols themselves have no concept of authorization scoping. Look at the Agent Skills distribution model: you distribute Skills via a git repository or a plugin. There's no concept of a user, a team, or a role. These weren't designed with the assumption that a whole company would be plugged into the same set of tools with the same level of access.

The natural pushback here is "but the MCP servers themselves have auth, so we're fine." And to be fair, if you force each end user to authenticate individually then they do get scoped by whatever permissions exist in the remote system. Your junior dev's Stripe MCP connection won't show them what the CFO's connection shows.

But it only covers half the problem. The other half is that your junior dev has a Stripe MCP at all. Even if Stripe rejects their queries or limits their visibility, the tool is sitting in their context. At best it's noise that degrades the quality of their AI interactions. At worst it's a security surface that doesn't need to exist. Your developers don't need Stripe. Your accountants don't need GitHub. Your marketing team doesn't need Datadog. The question isn't just "what can this person do with this tool" but "should this person have this tool in the first place."

And even where per-user auth does apply, you're relying on a patchwork of permission models across every connected system to collectively enforce your access policy. Every MCP has its own auth model, its own granularity, its own gaps. That's not a security posture, that's a prayer. What's missing is a single layer above all of it that governs which MCPs and Skills are even reachable for a given role before any of that downstream auth comes into play.

Meanwhile the role of people in companies hasn't changed at all. You wouldn't give your accountant access to the AWS CLI and you wouldn't give your developer access to Stripe and QuickBooks. We have always scoped information access to the role. AI makes this more important, not less, because the barrier to pulling sensitive data just went from knowing SQL or navigating a complex dashboard to typing a sentence in plain English.

We've had the answer for decades. Now we apply it to AI.

RBAC, role-based access control, has never been sexy. But it's the missing layer in the AI tooling stack, not at the model level, not at the MCP server level, but at the orchestration layer where Skills and MCPs get assigned to people. In a world where MCPs and Skills matter as much as code, where they are the data access and workflow engine for your everything application, that's the right surface for access control.

In practice this looks like a management layer where you define your teams and their roles, then classify which Skills and MCPs, and which MCP auth levels, each team can access. Your accountants get accounting skills and they don't pollute their context with coding tools. More importantly they don't get access to things they shouldn't. Your engineering team gets Datadog and GitHub but doesn't see payroll. The principle of least access applied to the most powerful application your company has ever had.

Companies don't run on a flat structure and AI won't change that. Agent Skills and MCPs are game-changing, but only when they follow your existing access policies and security posture. This is the problem we built skills.new to solve. One place to manage, govern, and secure all of your AI assets so your whole company can safely adopt the everything application instead of pretending that connecting everything to everyone is a strategy.