Agent → Registry
Requests may be routed and scoped here, but registry participation does not imply authority over device-side execution.
Public threat summary
Myosotis Threat Model
This page summarizes the governing threat model for Myosotis. It is derived from the RFC set and focuses on trust boundaries, threat expansion in federated execution, and the security invariants the architecture is intended to preserve.
Trust boundaries
Myosotis treats all major actors as untrusted by default: agents, devices, tools, and central coordination systems. Trust is not inherited from placement in the architecture. It is established only through explicit scope, local policy enforcement, cryptographic provenance, and attributable audit.
Registry → Device
Resolution and authorization metadata are advisory until the device validates policy locally.
Device → Policy
Local policy remains the final decision point for execution, consent, and capability scope.
Policy → Tool
Tool access must remain narrow, explicit, versioned, and auditable.
Primary threats
Federation and field execution introduce additional risk beyond a single-device or cloud-first model. The threat model expands to cover coordination, distribution, and operator-legibility failures.
- Cross-device capability escalation, where coordination could be used to expand authority across endpoints without explicit approval.
- Registry poisoning, where compromised or misleading coordination metadata attempts to influence device-side behavior.
- Fleet policy overreach, where ownership or organizational context is used to mask unsafe or overly broad authority.
- Hidden aggregation or ambiguous execution scope, where operators are not clearly informed which devices acted and under what conditions.
- Supply-chain and tool-verification failures, where unsigned or mutable tools could bypass execution guarantees.
Mitigation posture
The architecture responds to these threats with signed manifests, device-side enforcement, hardware-backed identity, explicit consent triggers, immutable audit behavior, and fail-closed execution rules.
Central systems may coordinate, but they do not silently collapse the trust boundary between request and execution.
Security invariants
No remote authority
Device-local policy remains the final authority for execution.
No implicit trust from federation
Multi-device coordination does not expand authority by default.
No hidden execution scope
Operators must be able to understand what executed, where, and why.
No silent degradation
Ambiguity, timeout, or audit failure resolve into bounded failure states.
No mutable trust surface
Tools and policies require explicit definition, verification, and review.
Source RFCs
This summary is primarily derived from RFC-002, RFC-010, RFC-011, RFC-012, RFC-013, and RFC-014, with supporting constraints from the reference architecture and whitepaper derivation rules.