coilyco-flight-deck/otel-a2a-relay
1
0
Fork 0
Code Issues 12 Pull requests Projects Releases Packages Wiki Activity Actions

Threat model: design + strategy parent #3

New issue
Open
opened 2026-05-23 20:55:17 +00:00 by coilysiren · 0 comments
coilysiren commented 2026-05-23 20:55:17 +00:00
Owner
Copy link

Originally filed by @coilysiren on 2026-05-08T12:16:39Z - https://github.com/coilysiren/otel-a2a-relay/issues/101

Parent issue for working through the o2r threat model. Authoring this is a prerequisite for the encryption / signing / key-management cluster (#77, #79, #80, #83, #85) and the cross-tenant attack tickets (#49, #52, #53).

Open questions

These need answers before any child ticket in the cluster can move autonomously.

Trust boundaries

  • Who's trusted: the relay operator? Each tenant agent? The OTel backend? The wire-format consumer?
  • Which combinations are explicitly distrusted: tenant-to-tenant? Relay-to-tenant? Backend-to-relay?

Attacker capabilities

  • Defending against malicious tenant attempting cross-tenant span injection?
  • Defending against a malicious OTel sink that scrapes attributes?
  • Defending against a compromised relay operator (insider threat)?
  • Defending against passive wire-format observers?

Out-of-scope attacks

  • Rubber-hose / coercion - out.
  • Side channels (timing, cache) - in or out?
  • Supply-chain attacks on dependencies - out (covered by supply-chain-audit).
  • Prompt injection via attributes - in scope, see #53.

Defense ordering

  • Which mitigations are 'must ship before public': encryption at rest? Signed spans? Tenant isolation tests?
  • Which are 'nice to have once primary defenses land': selective disclosure (#80), Merkle roots (#79)?

Output

A docs/threat-model.md (or section in docs/protocol.md, see #83) that:

  1. Names the boundaries.
  2. Names the attackers.
  3. Names what's protected and what isn't.
  4. Cross-links each downstream cluster ticket as 'this addresses attacker class X'.

Children unblocked once this lands

  • #83 - threat model section in docs/protocol.md (this issue's deliverable)
  • #79, #80, #85, #77 - encryption / signing / key-management
  • #49, #52, #53 - cross-tenant + prompt-injection attack tests

This issue stays open as the design home until the threat model doc is committed; then close and link.

_Originally filed by @coilysiren on 2026-05-08T12:16:39Z - [https://github.com/coilysiren/otel-a2a-relay/issues/101](https://github.com/coilysiren/otel-a2a-relay/issues/101)_ Parent issue for working through the o2r threat model. Authoring this is a prerequisite for the encryption / signing / key-management cluster (#77, #79, #80, #83, #85) and the cross-tenant attack tickets (#49, #52, #53). ## Open questions These need answers before any child ticket in the cluster can move autonomously. ### Trust boundaries - Who's trusted: the relay operator? Each tenant agent? The OTel backend? The wire-format consumer? - Which combinations are explicitly distrusted: tenant-to-tenant? Relay-to-tenant? Backend-to-relay? ### Attacker capabilities - Defending against malicious tenant attempting cross-tenant span injection? - Defending against a malicious OTel sink that scrapes attributes? - Defending against a compromised relay operator (insider threat)? - Defending against passive wire-format observers? ### Out-of-scope attacks - Rubber-hose / coercion - out. - Side channels (timing, cache) - in or out? - Supply-chain attacks on dependencies - out (covered by supply-chain-audit). - Prompt injection via attributes - in scope, see #53. ### Defense ordering - Which mitigations are 'must ship before public': encryption at rest? Signed spans? Tenant isolation tests? - Which are 'nice to have once primary defenses land': selective disclosure (#80), Merkle roots (#79)? ## Output A docs/threat-model.md (or section in docs/protocol.md, see #83) that: 1. Names the boundaries. 2. Names the attackers. 3. Names what's protected and what isn't. 4. Cross-links each downstream cluster ticket as 'this addresses attacker class X'. ## Children unblocked once this lands - #83 - threat model section in docs/protocol.md (this issue's deliverable) - #79, #80, #85, #77 - encryption / signing / key-management - #49, #52, #53 - cross-tenant + prompt-injection attack tests This issue stays open as the design home until the threat model doc is committed; then close and link.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
dependabot/uv/uv-e1a0e186ab
No results found.
Labels
Clear labels
  
P0
now / blocking / urgent

  
P1
next / important

  
P2
backlog / will do

  
P3
someday / low

  
P4
icebox / frozen / reopen if it becomes real

No labels
P0
P1
P2
P3
P4
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
coilyco-flight-deck/otel-a2a-relay#3
No description provided.