Cache freshness is a security decision because an old card can preserve permissions for an agent that no longer deserves them.
Why this question matters
A2A discovery guidance recommends ordinary HTTP caching tools such as Cache-Control and ETag. That improves latency and avoids repeated downloads. The difficult part is that different fields have different risk clocks. A skill description may be stable for months while a signing key or provider relationship can become invalid in minutes.
A cache therefore needs more than one expiration policy. Clients should distinguish descriptive metadata from security-sensitive claims and support urgent invalidation. Otherwise a signed but stale card can keep routing work to a compromised endpoint or conceal a change in who operates the runtime.
Signals worth observing
- The endpoint or provider changes without a corresponding version change.
- A card remains in use after its signing key is revoked or rotated.
- Different clients observe conflicting versions of the same agent identity.
Practical control direction
- Use shorter freshness windows for keys, endpoints, and security schemes.
- Bind ETags to the complete security-relevant representation.
- Support revocation notices that bypass normal cache lifetime.
AgentCollusion lensA trust graph must record which card version informed each decision, not merely the agent name.
