Signed AgentCard always has empty skills/capabilities in automated deploy path

[pdettori]

Summary

The automated deployment path produces a signed AgentCard with empty skills and capabilities. The signing infrastructure works correctly, but the content pipeline into it doesn't carry the agent's real capabilities.

Current Behavior

1. The backend creates <name>-card-unsigned ConfigMap with a hardcoded skeleton:

   {"name": "<name>", "url": "...", "capabilities": {}, "skills": []}

   (kagenti/backend/app/routers/agents.py — _ensure_card_unsigned_configmap)

2. The sign-agentcard init container signs this skeleton with the pod's SPIRE SVID and writes to /app/.well-known/agent-card.json

3. The controller fetches the signed-but-empty card from the live endpoint and verifies the signature

Result: The signed card is always empty, and the rich card (from the agent framework) is always unsigned. There is no automated path for a developer to get a signed AgentCard with the agent's true capabilities.

Current Workaround

ensure_configmap is create-if-not-exists, so pre-creating the ConfigMap with real content (as in demos/agentcard-spire-signing/) prevents the backend from overwriting it. Editing the ConfigMap post-deploy and bouncing the pod also works. Both require manual/GitOps intervention.

Proposed Solutions

These are not mutually exclusive:

1. Accept skills/capabilities in the deploy API

Extend CreateAgentRequest so the backend populates the unsigned ConfigMap with real content at creation time. Simplest change; works for agents whose capabilities are known at deploy time.

2. Two-phase sign: fetch-then-sign

After the agent is running, a controller or CronJob fetches /.well-known/agent-card.json from the live agent, patches the unsigned ConfigMap with the real content, and triggers a pod restart to re-sign. Handles agents whose capabilities are discovered at runtime (dynamic skills, plugin-loaded tools, etc.).

3. Agent-side signing

Instead of an init container signing a static ConfigMap, the agent framework itself signs the card using the SPIRE SVID at startup. The SDK calls the Workload API, signs its own dynamically-generated card, and serves the signed version directly. No ConfigMap needed. Most A2A-native approach but requires SDK integration.

References

• kagenti/backend/app/routers/agents.py:2029-2060 — _ensure_card_unsigned_configmap
• kagenti-operator/cmd/agentcard-signer/main.go — signer init container
• kagenti-operator/internal/controller/agentcard_controller.go:220-232 — controller fetch + verify
• kagenti-operator/demos/agentcard-spire-signing/ — working demo with manually crafted ConfigMap

[rhuss]

I would opt for Option 3 to avoid split brain situations, reduce the burden on the deployment process, avoid race conditions and since the developer need to modify there code anyway to wrap the A2A SDK http service around the agent runtime, it should be possible to include the signing in those client libs as well.

[kevincogan]

Option 4: Operator-side signing with HTTP fetch (bridge to Option 3)

@rhuss Agreed that agent-side signing (Option 3) is the cleanest end state. Long term that's where we should land.

The practical blocker is the multi-language challenge you raised in Slack around the A2A SDK being Python-specific. The same problem applies to Option 3: SPIFFE signing in the SDK means every language needs the integration, and it won't work for third-party or opaque agents like OpenClaw. Operator-signing covers all of these and becomes the permanent fallback even after Option 3 is available.

Proposal

PR #284 already adds the core infrastructure for the operator to sign AgentCards with its own SPIFFE identity during reconcile. To close this issue, I'll update the PR to fetch from the live agent endpoint via HTTP (using DefaultFetcher) and remove the init-container signer and all ConfigMaps from the signing pipeline (card-unsigned and card-signed). Operator-signing becomes the default behavior when signature verification is enabled.

The flow:

1. Agent starts, serves its real card at /.well-known/agent-card.json with full skills/capabilities
2. Controller waits for the workload to be ready, fetches the rich card via HTTP
3. Operator signs it with its own SVID and stores it in the AgentCard CR status
4. Every reconcile (default 30s), the operator re-fetches and re-signs

No ConfigMaps in the pipeline. The live agent endpoint is the source of truth for content, the AgentCard CR is the source of truth for the signed card. Split brain is bounded by the reconcile interval, and the AgentCard CR only reflects the controller's latest sync, so consumers never see a stale card.

Proposed path

Phase	What	Coverage
Now	Operator-signing with HTTP fetch (PR #284 + fetcher fix)	Every agent, every language
Next	Agent-side signing in the Python A2A SDK as reference impl	Python SDK agents
Later	Other SDKs adopt; operator-signing becomes fallback	Full ecosystem

The verification logic doesn't care who produced the signature, so Option 3 layers on top without any operator-side changes.

WDYT? @rhuss @pdettori

[pdettori]

@kevincogan I agree that indeed option 3 may be a problem due to lack of support in current SDKs, so I would prefer an option 4 as an operator-based solution with a single source of truth.

[kevincogan]

Thanks @pdettori, I'm wrapping up final testing for Option 4: Operator-side signing (#284). I'll push the latest changes and have it ready for review in the morning.

[rhuss]

Thanks @kevincogan, eliminating the ConfigMap pipeline and using the live endpoint as source of truth is the right direction. But I don't think Option 4 as described can ship without addressing two fundamental problems.

1. The HTTP fetch is unauthenticated and unencrypted

The operator fetches via http://<agent>.<ns>.svc.cluster.local, plaintext HTTP. This opens concrete attack vectors:

• MITM: An attacker intercepting pod-to-pod traffic (compromised node, rogue pod with NET_RAW) returns a modified card. The operator signs the tampered content. You now have an operator-attested, signed, fake card in the AgentCard CRD.
• Service hijacking: A rogue pod with matching labels (kagenti.io/type: agent, app.kubernetes.io/name: <target>) receives the operator's request and serves a fake card that gets signed.
• No agent authentication: The operator connects over HTTP, not mTLS. The agent doesn't present a client certificate. The operator trusts Kubernetes Service routing (label-based), not cryptographic identity.

The current init-container model avoids all three because signing is local (no network request). It signs empty content, but at least the signing itself is tamper-proof.

2. The agent's SPIFFE ID is lost from the signature

Under Option 4, the JWS x5c chain contains the operator's certificate, so signatureSpiffeId becomes the operator's SPIFFE ID. The cryptographic binding between "agent workload identity" and "card content" is gone.

Even with mTLS on the fetch (which would close the attack vectors above), the JWS signature is still produced by the operator's private key. mTLS proves the agent's identity during the TLS session, but that proof is ephemeral and doesn't end up in the JWS unless explicitly embedded.

To preserve the agent's identity in the signed artifact, the operator would need to act as a notary: verify the agent's SVID via mTLS during fetch, extract the SPIFFE ID from the client certificate, and embed it as a claim inside the signed payload (either a custom JWS header field like agent_spiffe_id, or a new field on AgentCardData itself). The x5c chain stays the operator's (the notary's signature), but the document contains the identity of the agent it's about.

Without this, consumers can't distinguish "operator attests card for legitimate agent X" from "operator attests card for rogue agent pretending to be X."

What I think is needed for Option 4 to work

1. mTLS on the fetch using the SPIRE Workload API (operator already has access). This closes MITM, hijacking, and authenticates the agent.
2. Embed the verified agent SPIFFE ID in the signed payload (from the mTLS client certificate). This preserves identity binding in the notarial model.
3. Document the trust model clearly: this is operator-attestation ("the operator verified agent X serves this card"), not agent self-attestation.

Without at least (1) and (2), we're replacing a broken-but-secure signing model (empty content, strong identity) with a useful-but-insecure one (real content, no identity, tamperable fetch). For a platform that markets zero-trust agent security, I don't think that trade-off works.

And even introducing mTLS without a hard dependency on a service mesh is a challenge on its own, as we have seen in the discussion around token exchange.

Option 3 (agent-side signing) remains the cleanest end state since both the content and the identity come from the agent itself, no network fetch needed. I'd suggest treating it as a priority follow-up rather than "later."

[grs]

Another option is to use the sidecar. Rather than passing the request for the agent card through as is, the sidecar can retrieve (and cache) the unsigned card from the agent over localhost, sign it using the SPIFFE credentials it already has access to, then cache and return the signed card.

This also avoids having to restart pods to pick up rotated credentials.