Source-linked AI summary
Skill-as-API: Confidential Multi-Agent Coordination for Agentic Software Engineering
Ziwei Zhao, Yu Gu, Haojun Liang, Chen Zhang, Xizhi Ding
TL;DR
Collaborating coding agents can expose proprietary skill methodology through coordination protocols that publish discovery metadata and cannot hide skill existence or wrapped prompts. Skill-as-API keeps skill bodies in the owner’s process while adding access-control layers; its three-agent review case study illustrates trust-tiered access and task-bounded permissions alongside 1.8–2.9 s cross-continent hot-reconnect latency.
Problem
MCP and A2A expose skill names, descriptions, and typed schemas to peers and cannot hide skill existence or keep wrapped prompts off the discovery surface, risking disclosure of proprietary methodology.
Source: §1 · p. 1Method
Skill-as-API limits the public view to a skill’s name, description, and typed schemas while closure-capturing its code and system prompt in the owner’s process.
Source: §1 · p. 1Results
Takeaways & Limitations
After a one-time PR review, permissions decay toward a KNOWN floor rather than leaving a permanent skill-access channel.
Source: §4 · p. 4, §6 · p. 4Cross-step input poisoning remains unaddressed: forwarded agent output is unsanitized, and an orchestrator-level sanitizer is future work.
Source: §6 · p. 4
Abstract
from arXiv · showhide
AI coding agents are evolving from solitary tools into collaborative teammates that discover and invoke one another's specialized skills. But the coordination channel itself can leak a skill's intellectual property. Protocols such as MCP and A2A run implementations server-side, yet they still publish each skill's description and typed schemas to every peer, offer no way to hide a skill's existence, and cannot guarantee that a wrapped system prompt stays off the wire. Application-layer privacy filters help, but act only after the model has decided to emit sensitive text. We take a complementary, protocol-layer route: Skill-as-API, a coordination protocol whose public view of a skill is limited to its name, description, typed input/output schemas, and trust tier. The skill body is closure-captured in the owner's process and never crosses the wire. Four layers add access control and narrow the prompt-injection surface structurally rather than by filtering content. We provide an open-source Python implementation over XMTP with 1.8-2.9 s cross-continent hot-reconnect latency, and a software-engineering case study in which three agents coordinate a pull-request review while each retains ownership of its proprietary analysis prompts.
1 Introduction
As AI agents collaborate across organizational boundaries, their coordination protocols can expose proprietary skill methodology even when skill implementations stay server-side. Skill-as-API keeps the skill body in its owner’s process while supporting multi-agent software-engineering workflows.
1 Introduction
- Cross-organizational collaboration among autonomous agents is presented as a hallmark of SE 3.0, where human engineers orchestrate agent fleets.Examples include invoking another team’s security-scanning agent or delegating incident triage to a vendor agent.Source: §1 · p. 1
- MCP and A2A publish skill names, descriptions, and typed schemas to peers, cannot hide skill existence or keep wrapped prompts off discovery, and leave valuable methodology exposed.Application-layer filters intervene only after the model has decided to emit sensitive content.Source: §1 · p. 1
- Skill-as-API limits a skill’s public view to its name, description, and typed input/output schemas, while its body remains in the owner’s process.The paper positions it as complementary to MCP and A2A when skill IP must be protected.Source: §1 · p. 1
- The protocol adds trust tiers, auto-downgrade, skill hiding, and a function-boundary defense under the invariant that the body never enters the public view.Together, these mechanisms address access and confidentiality at the protocol layer.Source: §1 · p. 1
- The described system runs over XMTP and achieves cross-continent hot-reconnect latency of 1.8–2.9 s, with no Python-side dependencies beyond the standard library.Source: §1 · p. 1
- A three-agent pull-request review case study demonstrates trust tiers, skill hiding, and injection absorption in a realistic software-engineering workflow.Each agent retains ownership of its proprietary analysis prompts.Source: §1 · p. 1
2 Motivation and Threat Model
The threat model centers on extracting proprietary skill methodology, stealing prompts through injection, and retaining elevated trust beyond a collaboration episode. It motivates design goals that bound what peers can observe, who can access skills, and for how long.
2.1 Threats in SE Agent Collaboration
- The three identified threats are skill-IP extraction through code, prompt, or namespace attacks; prompt theft via injection; and trust drift that can turn temporary collaboration into lasting access.Unbounded trust accumulation is especially dangerous in transient cross-organizational collaboration.Source: §2.1 · pp. 1–2
2.2 Threat Model
- The threat model assumes the owner’s machine is uncompromised and excludes attacks on the caller’s own LLM stack.Colluding callees and schema-inference attackers are partially in scope; the protocol reduces but does not eliminate these risks.Source: §2.2 · p. 2
2.3 Design Goals
- The design goals require non-transmission of code and prompts, indistinguishable errors for hidden or forbidden skills, trust decay on completion, function-boundary prompt protection, and low-single-digit-second hot reconnect.The goals control what a peer can observe, who may observe it, and for how long.Source: §2.3 · p. 2
3 The Skill-as-API Protocol
Skill-as-API fixes the public skill view and adds four layers governing invocation and extraction. The skill body stays in the owner’s process while trust, discoverability, and prompt-injection exposure are constrained by protocol design.
3 The Skill-as-API Protocol
- The protocol combines a fixed public skill view with four layers addressing trust drift, skill enumeration, and prompt injection.The layers are trust-tier access control, auto-downgrade, skill hiding, and function-boundary defense.Source: §3 · p. 2
3.1 Core Abstraction
- A skill exposes metadata and typed schemas, while its code and system prompt remain owner-side; invocation filters input to the declared schema.The prompt is closure-captured at registration and is not a function parameter or reachable from the input path.Source: §3.1 · p. 2
3.2 Layer 1: Trust-Tier ACL (→T3)
- Invocation requires a peer’s trust tier to meet the skill’s minimum tier, and inbound message types are gated by a fixed table with unknown types denied by default.The tiers are UNTRUSTED, KNOWN, INTERNAL, and PRIVILEGED.Source: §3.2 · p. 2
3.3 Layer 2: Auto-Downgrade (→T3)
- Trust decays rather than accumulates: three consecutive failures drop a peer one tier, and completing a collaboration OKR removes one tier with a KNOWN floor.Peers must earn evidence for future re-elevation rather than retain standing access.Source: §3.3 · p. 2
3.4 Layer 3: Skill Hiding (→T1)
- Hidden and nonexistent skills return the same error string, while owner-side logs distinguish them; timing differences remain a side channel.Randomized delays are future work.Source: §3.4 · p. 2
3.5 Layer 4: Function-Boundary Defense (→T2)
- The function boundary keeps caller input out of the system-role prompt, but a callee model may still recite the prompt in response to user-turn injection.The layer protects only the callee; a caller that feeds returned values into its own LLM remains exposed to ordinary injection.Source: §3.5 · p. 3
3.6 Implementation
- The reference Python implementation uses a Node.js XMTP sidecar and reports 1.8–2.9 s hot-reconnect latency; failure counters reset on restart and versioning uses exact-string equality.The Python core communicates with the bridge over localhost HTTP/SSE.Source: §3.6 · p. 3
4 SE Case Study
The case study exercises schema-only discovery, injection absorption, and trust decay in a three-agent pull-request review. It reports a 10/10 injection spot-check, permission decay after completion, and 1.8–2.9 s hot-reconnect latency.
G1 verification: schema-only view
- The orchestrator discovered only the code-review skill’s name, description, and typed schemas, with no checklist prompt in logged XMTP messages.The checklist contained about 1,200 characters of proprietary review methodology.Source: §4 · p. 3
G4 verification: injection absorption
- 10/10 task inputs were absorbed, with the system prompt absent from returned fields and the output schema preserved.The authors describe this as an illustrative spot-check, not a bound on residual leakage; with N=10, zero leakage cannot tightly bound that rate.Source: §4 · p. 3, Table 2 · p. 4
G3 verification: trust decay on OKR completion
- After the collaboration OKR was marked complete, both specialists decayed from INTERNAL to KNOWN, and a subsequent INTERNAL-tier invocation was denied.The run also verified a PRIVILEGED-to-INTERNAL transition on a test peer.Source: §4 · pp. 3–4
Latency
- Hot-reconnect latency was 1.8–2.9 s across 30 calls, while first-ever channel establishment took 30–60 s.The hot-reconnect measurements used two intercontinental XMTP relay endpoints; cold start was dominated by XMTP MLS group formation.Source: §4 · p. 4
Limitations observed
- The orchestrator forwards the code-quality agent’s output to the security agent without sanitization, leaving cross-step input poisoning unaddressed.The paper identifies an orchestrator-level sanitizer as future work.Source: §4 · p. 4
5 Related Work
Related work spans encryption, identity-and-access gating, and inference-time content filtering; Skill-as-API adds a complementary protocol strategy that changes what is exposed on the wire. The paper also relates this boundary to prior agent-security, capability-system, and software-engineering agent work.
Agent-privacy strategies
- Skill-as-API adds a complementary ABI-layer strategy to encryption, IAM gating, and inference-time filtering; the latter approaches have distinct overhead and residual-leakage trade-offs.The cited comparison reports 2–3 orders-of-magnitude overhead for generic HE/MPC techniques and a ∼7–8% residual for PrivacyChecker in its reported settings.Source: §5 · p. 4
Multi-agent coordination protocols
- MCP transmits tool descriptions and schemas, while AgentNet decentralizes coordination without addressing skill-IP protection.Table 3 is identified as a protocol comparison, but its caption alone does not specify individual comparison outcomes.Source: §5 · p. 4, Table 3 · p. 4
Capability systems
- Skill-as-API adapts the capability-system intuition of restricting reachable resources at language and operating-system boundaries to the agent ABI.The cited antecedent is Capsicum.Source: §5 · p. 4
SE agent systems and agent security
6 Conclusion
The conclusion presents Skill-as-API as a protocol for keeping skill bodies in their owners’ processes while adding trust controls and a function-boundary defense. It reports an illustrative three-agent case study and identifies residual risks and future work.
Conclusion
- Skill-as-API keeps skill bodies in the owner’s process and combines trust-tier access control, auto-downgrade, skill hiding, and a function-boundary defense.The paper describes these layers as narrowing the prompt-injection surface structurally.Source: §6 · p. 4
- In the three-agent pull-request review case study, trust tiers governed access, permissions decayed toward KNOWN after completion, and hot-reconnect latency was 1.8–2.9 s.The reference implementation is open-source and runs over XMTP.Source: §6 · p. 4
Limitations and future work
- The paper leaves cross-step input poisoning, application-level leakage, timing side-channels, per-skill ACLs, and residual collusion or schema-inference risks unresolved or for future work.The authors also state that their vision is an SE 3.0 ecosystem in which agents collaborate while retaining ownership of their engineering methodology.Source: §6 · p. 4