The Skill Ecosystem Has a Locked Door Problem — So I'm Building the Lock

I've been using Claude Code and agent skills heavily for the past several months. At some point it clicked: the model is just the engine. The skill is the intelligence.

That realization led me to a question that I couldn't find an answer to anywhere: if skills are this valuable, why does the entire skill ecosystem treat them like open-source recipes that anyone can copy?

What's Broken Today

Right now, every AI agent skill — on every marketplace — is a plain-text Markdown file sitting on someone's computer. Install a skill from SkillsMP, skills.sh, or any other registry, and you get the full instructions. Every carefully crafted prompt, every heuristic the creator spent months refining, right there in a file you can open in any text editor.

That's great for community sharing. It's a complete non-starter for enterprises.

Think about who should be participating in the skill ecosystem but isn't:

• A law firm with a proprietary contract review methodology
• A hospital with a clinical documentation workflow refined over years
• A financial institution with a compliance checking process
• A consulting firm with a research framework they spent years developing

None of them can publish their skills today. The moment they do, they hand their IP to anyone who installs it. So they don't publish. And the ecosystem loses the most valuable expertise.

Why MCP Doesn't Solve This

My first thought was: doesn't MCP already handle this?

MCP (Model Context Protocol) is excellent for what it does — connecting agents to tools, databases, APIs. I'm a fan. But MCP answers a different question.

MCP: How does an agent connect to an external service?

The problem I'm describing: How does an agent use a skill whose instructions should remain private?

Some enterprise launch partners (Atlassian, Canva, Cloudflare) have figured out a hack: ship a thin public SKILL.md that just calls a private MCP server. It works, but it's not a standard. Every company invents their own approach. There's no auth convention. There's no discovery mechanism. There's no billing layer.

The Three Missing Pieces

I see three things missing from today's skill ecosystem:

1. Hide the recipe. There's no standard for a skill creator to keep their instructions private while still letting agents invoke the skill. You either ship the file or you don't participate.

2. Control the door. Once a skill is installed, there's no authentication. Anyone with the file can use it freely. No standard way to say "only my paying customers can invoke this."

3. Get paid. There's no billing layer in any skill standard. If you want to charge for a skill, you build a completely custom payment system outside the protocol.

Introducing PASE

I've written and published a draft specification called PASE — Private Agent Skill Endpoint.

The core idea: instead of shipping a skill as a file, you ship it as a remote endpoint. The consumer agent calls the endpoint, authenticates, and gets the output. The instructions never leave your server.

Today's skills are recipes on index cards. PASE turns them into restaurants. The diner gets the meal. They never get the recipe.

What a PASE manifest looks like

---
name: contract-redline
description: ">"
  Reviews vendor contracts against standard corporate playbook.
  Use when reviewing any vendor agreement or SaaS contract.
endpoint:
  url: https://skills.example.com/contract-redline
  protocol: pase/1.0
authorization:
  server: https://auth.example.com
  scopes: [skill:invoke]
---

# Public description only.
# Actual instructions hosted privately.

That's it. The public manifest tells agents what the skill does and where to call it. The instructions stay on your server.

What PASE builds on

PASE doesn't invent anything new. It composes existing open standards:

• SKILL.md — the existing agent skills format (just extended with an endpoint block)
• OAuth 2.1 + PKCE — the same auth standard MCP uses
• x402 — the Linux Foundation's HTTP payment standard, for optional billing
• JSON-RPC 2.0 over HTTPS — the same transport as MCP

If you already implement MCP with auth, you're 80% of the way to a PASE-compliant endpoint.

Why Now

The Agent Skills ecosystem is roughly six months old. SKILL.md became an open standard in December 2025. Every major AI platform has adopted it. The open skill layer has standardized.

The private skill layer has no standard. Enterprise adoption is currently blocked by this exact gap. This is the window.

All three of the pieces PASE needs — SKILL.md, MCP's OAuth spec, and x402 — are already under Linux Foundation governance. PASE composes them. The goal is that PASE eventually lives there too.

Current Status

This is a v0.1 draft specification. I've published three documents:

• README.md — plain English overview and use cases
• SPEC.md — the full technical specification
• MOTIVATION.md — the reasoning behind every design choice

GitHub: github.com/amitgandhi18/pase

What I'm looking for right now:

1. Does this match a real pain you've experienced? Tell me in the comments or open a GitHub issue.
2. Technical feedback — especially from people who know OAuth 2.1, MCP internals, or x402.
3. Early implementers — if you're building an agent runtime and would consider implementing this, I want to talk to you.

The spec is a document, not code. It takes one commit to plant a flag. The hard part is getting the right people to read it.

Amit Gandhi · @amitgandhi18