Progressive Skill Discovery as Access Control for Tool-Using LLM Agents

What it is

Skilder (Stettler et al., arXiv:2609.28693, May 2026, from skilder.ai) is an MCP server that gates enterprise tool access behind roles — bundles of skills, tools, instructions, and limits that an agent must learn before the tools become callable. The summary has the concept; what it omits is the two caveats that reframe the headline "zero unauthorized calls" result, plus the concrete architecture an engineer would need to evaluate the claim.

How it works

The agent connects to Skilder and sees only four platform tools:

• init_skilder — returns the role catalog for the session's fixed authorization scope (names, descriptions, skill names, learn paths; no tools or instructions yet)
• learn — three levels: /roles/<name> returns a role's instructions + skills and unlocks its tools; /<skill> re-reads one skill; /<skill>/<resource> fetches an attached document
• call_tool — executes a domain tool only if it belongs to a learned role; otherwise returns ACCESS DENIED with the available-tool list
• feedback_skill — rates a skill

The check that gates call_tool is called the router. Tools never delivered inside a learned skill cannot be called — enforcement is at the interface, before the model, not in the prompt.

What to do — and what to weigh first

Two caveats the paper states plainly and the summary drops:

1. **The results come from a simulated authorization layer, not the live product.** The harness (built on promptfoo) uses "a simulated authorization layer that copies the Skilder role design… and fake domain-tool data. Results measure this test design, not a live product snapshot." Treat "zero unauthorized tool call or parameter violation" as a property of the test harness, not a pen-test of shipping software.

1. "Zero authorization failures" only counts trials that reached the router. The paper splits Skilder failures into two buckets: the model never reached the router (didn't finish init→learn, picked the wrong role, or failed a wording check) versus the router was tested. Qwen 3.5 and Ministral 3 14B "land here often" — they struggle with the progressive-discovery protocol. So the enforcement guarantee is conditional on the model completing discovery, and that completion is model-dependent.

Also note the behavioral-comparison caveat: the multi-agent baseline gets a larger effective inference budget and places specialist instructions at higher prompt priority, while Skilder adds a discovery protocol overhead. Pass-rate differences between conditions "measure this whole setup, not router reliability in isolation."

Preconditions / Affected

• Models tested: Claude Haiku 4.5, Qwen 3.5 122B, Gemma 4 31B, Ministral 3 14B, Claude Opus 4.7, GPT-5.5 (token studies use Sonnet 4.5 only). Haiku, Gemma, and GPT-5.5 matched flat-injection on normal tasks; the weaker/open models did not reliably complete discovery.
• Harness path prefix in the recorded runs was hats/, since renamed to /roles/<name> — transcripts you see quoted may use the old term.
• Scenarios 1–10 run 10 trials each; institutional scenarios 11–13 run 5.

Caveats

The paper is explicit that behavioral pass-rate misses under the Skilder condition are "real end-to-end limitations" but "do not show that access control failed." Conversely, the access-control success is bounded by the simulation. If you are deciding whether to adopt, the actionable takeaway is: the design deterministically blocks unlearned tools, but the evidence is a simulated harness, and delivery depends on the model reliably navigating init→learn→call_tool.