Capability marketplace part 2: federated cross-agent discovery

[dgenio]

Parent: #49 | Split: Federated cross-agent discovery

Problem

This is part 2 of #49. With the manifest format and local registry in place (part 1), this issue adds federated multi-kernel discovery — the ability to find and import capabilities from remote kernels automatically.

High risk — protocol design needs careful security review. Consider writing a security design doc before implementation.

Proposed Change

1. Discovery protocol

manifests = await kernel.discover_peers(
    registry_url="https://registry.example.com/manifests",
    # or
    peer_urls=["https://agent-b.internal/kernel/manifest"],
)
for manifest in manifests:
    kernel.import_remote(manifest, ...)

2. Security boundaries

• Remote capabilities go through the full local pipeline: local policy → local token → local firewall.
• No direct driver access is exposed — remote kernel's internal driver IDs are opaque.
• Sensitivity tags are the union (if remote says PII, local treats it as PII).

3. Manifest serving endpoint

• Optional HTTP endpoint that serves a kernel's manifest for peer discovery.
• Signed manifests for authenticity verification.

Acceptance Criteria

• kernel.discover_peers() fetches manifests from registry or peer URLs
• Periodic re-discovery with configurable interval
• End-to-end test: Kernel A imports from Kernel B → invokes → gets result through both firewalls
• Manifest signing and verification
• Rate limiting on discovery endpoint
• Security design doc reviewed before implementation

Affected Files

• src/agent_kernel/federation.py (extend with discovery)
• tests/test_federation.py (extend)
• docs/federation.md (extend with discovery protocol)

Dependencies

• Requires part 1 (manifest format & local registry)
• Optionally pairs with Capability namespaces & hierarchical discovery #45 (namespace support) for federated namespace resolution