5K

Black-Box Skill Invocation

Shares skills through input and output schemas only and runs them on the provider side, so prompts and code never cross the boundary

emerging Updated 2026-07-23 By Ziwei Zhao (@ZiwayZhao) Based on Capability-Based Security (Dennis & Van Horn, 1966), Remote Procedure Call (Birrell & Nelson, 1984)
View .md Edit on GitHub
Add to Pack
or

Saved locally in this browser for now.

Cite This Pattern
APA 
Ziwei Zhao (@ZiwayZhao) (2026). Black-Box Skill Invocation. In *Awesome Agentic Patterns*. Retrieved September 28, 2026, from https://agentic-patterns.com/patterns/black-box-skill-invocation
BibTeX 
@misc{agentic_patterns_black-box-skill-invocation,
  title = {Black-Box Skill Invocation},
  author = {Ziwei Zhao (@ZiwayZhao)},
  year = {2026},
  howpublished = {\url{https://agentic-patterns.com/patterns/black-box-skill-invocation}},
  note = {Awesome Agentic Patterns}
}

Use when

  • Agents from different organizations collaborate without exposing proprietary logic
  • Provider wants to offer a skill without revealing its implementation
  • Collaboration is temporary and trust must expire

Avoid when

  • Caller must inspect, debug, or verify how the skill ran
  • Schemas cannot express valid inputs for the skill

Problem

When agents collaborate by sharing skills, the typical approach exposes implementation details: source code, prompts, internal logic, and model configurations. This creates knowledge leakage — a collaborator's agent can learn and replicate proprietary workflows after a single interaction.

Traditional mitigations (NDAs, API gateways, access control lists) constrain humans but do not constrain agent memory. Once an agent observes implementation details during collaboration, the knowledge cannot be "unlearned."

Solution

Separate what a skill can do from how it works at the protocol level:

  • Schema-only discovery: Peers discover skill capabilities through input/output schema contracts (name, description, parameter types, return types, minimum trust tier). Implementation code, prompts, and internal logic are never transmitted.
  • Remote execution, local processing: The skill runs on the provider's machine. The caller sends structured input and receives structured output. No intermediate state, chain-of-thought, or model artifacts cross the boundary.
  • Uniform error responses: Hidden skills, nonexistent skills, and trust-insufficient skills all return the same generic error ("Unknown skill"), preventing existence enumeration.
  • Revocable trust tiers: Access is granted per collaboration, not permanently. Trust automatically downgrades when the task objective completes, ensuring short-term collaboration does not become long-term access.

The attack surface shrinks from "the entire LLM context" to "the function parameter boundary."

How to use it

  • Agents from different organizations need to collaborate without exposing proprietary logic
  • A skill provider wants to monetize capabilities without revealing implementation
  • Collaboration is temporary and trust should not persist indefinitely
  • Prompt injection defense is needed at the architectural level (not just prompt-level filtering)

Trade-offs

  • Pros: Prevents knowledge leakage across agent collaboration boundaries; enables monetization without IP exposure; reduces attack surface to parameter boundaries only.
  • Cons: The caller cannot inspect or debug the skill implementation — they must trust the output. Schema contracts must be expressive enough for valid input construction. Asynchronous execution is needed when the provider is not always online. No verifiable computation — the caller cannot prove the skill ran correctly.

References