Sharing an Agent's Capability Without Sharing the Company's Playbook
An engineer reviewing a partner integration faces an awkward choice. The partner's agent needs access to an internal code-review capability, but the checklist behind that capability contains proprietary instructions the company does not want to hand over.
Skill-as-API tests a different model: let the outside agent invoke the capability while keeping the code and system prompt inside the owner's environment. That creates a governance boundary between owning a procedure and being authorized to invoke it.
The paper, submitted to arXiv on September 1, 2026, describes a skill as two layers. The private body contains code and a system prompt. The public interface exposes enough information for another agent to discover and call the skill, including its name, description, routing hint, version, typed input and output schemas, minimum trust tier, and schema hash.
The caller can see what the capability does and how to invoke it. The procedure itself stays with the owner.
That is the architectural promise. The researchers then tested whether it held.
How the Mechanism Works
Peers are assigned one of four trust tiers: UNTRUSTED, KNOWN, INTERNAL, or PRIVILEGED. Each skill defines the minimum tier required for access. Skills can also be hidden from peers without sufficient authorization, and hidden and nonexistent skills return the same external error.
When an authorized caller invokes a skill, it sends the skill identifier and inputs. Those inputs are filtered against the declared schema and passed to the owner's local executor. The private system prompt is closure-captured when the skill is registered, so it is not transmitted with the request. Only the result crosses back to the caller.
Access is also designed to decay. Completing a collaboration lowers a peer's trust by one tier, with a floor at KNOWN, while three consecutive failures can also trigger a downgrade. In the case study, an orchestrator fell from INTERNAL to KNOWN after finishing a collaboration and then lost access to an INTERNAL-level skill until it sought elevation again.
Analysis
The governance significance is the separation of capability from implementation.
The researchers tested a roughly 1,200-character proprietary review prompt and found that it did not appear in the orchestrator's discovery messages or tool-call payloads. They also submitted 10 adversarial inputs across eight prompt-injection classes and observed no returned prompt content.
The prompt stayed put.
The authors are careful about what that proves. They describe the adversarial test as an illustrative spot-check, not a general leakage bound. The design prevents direct transmission of the private body, but it does not establish that a caller cannot infer the procedure indirectly.
Repeated legitimate outputs could still support statistical cloning, which the paper leaves outside scope. Behavioral prompt disclosure, schema inference, timing side channels, collusion, and cross-step output poisoning also remain unresolved or only partially addressed.
The boundary is therefore real, but narrow: the system can prevent the playbook from being handed over while still exposing a capability built from it.
Implications for Enterprises
That shifts the governance question from secrecy alone to evidence.
The reference implementation records caller identity, skill, inputs, outputs or errors, timestamps, duration, task identifiers, and message correlation information. Trust overrides are separately persisted. Those records can help answer who invoked a capability and what happened.
What they do not yet provide is a durable enterprise audit trail. Task and activity histories are not shown as tamper-evident records, and task records do not reliably bind an execution to the exact private procedure version that produced the result.
That gap matters because the schema hash covers public interface elements, not the private skill body. A company could change the underlying prompt without the hash proving which private instructions ran for a specific invocation.
For enterprise use, the access mechanism would need stronger surrounding controls: durable execution records, procedure-level version provenance, access reviews, revocation evidence, and organizational rules for granting trust.
Risks and Open Questions
The implementation also leaves several policy questions open. Trust is assigned per peer rather than through finer-grained per-skill ACLs. Failure counters reset when the process restarts. The released implementation can automatically accept trust requests up to a configured level.
The research also does not demonstrate controls over what an authorized caller does with returned results, whether repeated queries reveal proprietary methodology, or whether a valid invocation served an approved business purpose.
Keeping the playbook private solves one problem.
Governing the capability starts after that: proving who could use it, which procedure actually ran, and whether the organization can still reconstruct that decision when someone asks months later.
Further Reading
- Skill-as-API: Confidential Multi-Agent Coordination for Agentic Software Engineering
- Skill-as-API Reference Implementation
- Model Context Protocol Specification
- Agent2Agent Protocol Specification