Trusted Tool Set

[Mossaka]

Wassette should be configured in a way to trust a set of tools from a specific criteria. For example, I trust all "the microsoft/... tools". Need some research on what the UX would look like that builds on top of the wassette experience today.

[Mossaka]

/scout can you do some research?

Agentic Scout triggered by this comment

[github-actions]

🔍 Scout Research Report

Triggered by @Mossaka

Executive Summary

Wassette is positioned at the intersection of three rapidly evolving technologies: WebAssembly Components, Model Context Protocol (MCP), and OCI-compliant artifact distribution. Research indicates strong alignment with Microsoft's container security best practices and emerging standards in AI agent tooling. Key opportunities exist in enhanced security validation, expanded MCP ecosystem integration, and streamlined component distribution.

Click to expand detailed findings

Research Findings

1. WebAssembly Security & Sandboxing Best Practices

Current Industry Standards:

• WebAssembly sandboxing provides memory-safe, hardware-isolated execution environments comparable to browser-grade security
• Microsoft documentation emphasizes defense-in-depth approaches combining sandboxing with authentication, policy enforcement, and vulnerability scanning
• Key security principles identified:
  • Treat all external content (including Wasm components) as potentially untrusted
  • Implement least-privilege access controls at multiple layers
  • Use cryptographic signatures for artifact authenticity
  • Regular vulnerability scanning throughout the supply chain

Wassette's Security Posture:
✅ Strengths:

• Uses Wasmtime's robust sandboxing (industry-leading runtime)
• Implements granular permission system (storage, network, environment variables, memory limits)
• Policy-based access control with per-component configuration
• OS-appropriate secret storage (0700 permissions, user-only access)

📊 Alignment: Wassette follows Microsoft's recommended security patterns for isolated workload execution, similar to Azure Container Instances and AKS sandboxing approaches.

Recommendations:

1. Consider adding component signature verification using Notary Project/Notation for OCI artifacts
2. Document security audit procedures for component vetting (similar to container image scanning)
3. Add optional integration with vulnerability scanning tools for Wasm components

---

2. Model Context Protocol (MCP) Ecosystem Integration

MCP Adoption Landscape (2025):
Microsoft has significantly invested in MCP infrastructure:

• Azure MCP Server - Official server for Azure resource management
• Fabric RTI MCP Server - Real-time intelligence and data analytics
• Dynamics 365 MCP Servers - ERP/CRM integration for AI agents
• Visual Studio / VS Code - Native MCP client support
• Azure AI Foundry - Agent framework with MCP tool calling

Key MCP Architecture Patterns:

1. Tool Discovery - Dynamic capability negotiation between clients and servers
2. Structured Output - Type-safe responses using JSON Schema validation
3. Resource Management - Stateful interactions with external systems
4. Authentication - Entra ID integration for enterprise deployments

Wassette's MCP Implementation:
✅ Current Features:

• Implements MCP server protocol (rmcp v0.5.0)
• Supports structured output (as of v0.3.0)
• 12 built-in tools for component and permission management
• Multiple transport protocols (stdio, SSE, HTTP streamable)

🎯 Positioning: Wassette provides a unique value proposition - it's the only MCP server that enables dynamic loading of WebAssembly tools, making it extensible in ways traditional MCP servers are not.

Recommendations:

1. Publish Wassette to MCP Server Directory - Increase discoverability in the MCP ecosystem
2. Create integration examples with popular MCP clients:
   • GitHub Copilot agent mode
   • Claude Desktop
   • Azure AI Foundry Agent Service
3. MCP Resources - Consider adding MCP "resources" capability (not just tools) for exposing component metadata and documentation
4. Prompt Templates - Add MCP "prompts" feature to guide AI agents in using complex component workflows

---

3. OCI Registry & Artifact Distribution

OCI Standards Alignment:
Microsoft documentation confirms Azure Container Registry (ACR) and other OCI-compliant registries support:

• OCI Distribution Spec v1.1 - Standard for artifact push/pull
• OCI Image Format Spec - Container images, Helm charts, and custom artifacts
• OCI Referrers API - Linking supply chain artifacts (signatures, SBOMs, scan results)
• Notary Project integration - Cryptographic signing and verification

Wassette's Distribution Strategy:
✅ Current Implementation:

• Loads components from (redacted) URIs (e.g., (redacted))
• Component registry JSON for discovery
• Supports filesystem and OCI registry sources

Industry Best Practices for OCI Artifacts:

1. Image Signing - Use Notation/Notary for cryptographic signatures
2. Vulnerability Scanning - Microsoft Defender for Cloud integration
3. RBAC Permissions - Fine-grained repository-level access control
4. Content Trust - Verify artifact integrity before loading
5. Supply Chain Metadata - Attach SBOMs and scan results as OCI referrers

Recommendations:

1. Component Signature Verification:

   • Add --verify-signature flag to component loading
   • Integrate with Notation CLI for signature checking
   • Support Azure Key Vault and Trusted Signing for key management

2. Enhanced Registry Security:

   • Add support for private OCI registries with authentication
   • Document best practices for hosting private component registries
   • Consider registry mirroring/caching for offline scenarios

3. Component Metadata Standards:

   • Define standard annotations for Wasm components (WIT schemas, permissions required, etc.)
   • Use OCI artifact annotations for component discovery metadata
   • Support OCI referrers for attaching test results, SBOMs, and security scan reports

---

4. Component Discovery & Distribution

Current Component Registry Approach:
Wassette uses component-registry.json with entries like:

{
  "name": "Weather Server",
  "description": "A weather component written in JavaScript",
  "uri": "(redacted)"
}

Scaling Challenges:

• Manual curation doesn't scale to large ecosystems
• No versioning or compatibility metadata
• Limited search/filter capabilities
• No community contribution mechanism

Recommendations:

1. Enhanced Component Registry:

   • Add semantic versioning support with compatibility ranges
   • Include WIT interface definitions for type-safe discovery
   • Add tags/categories for better searchability (e.g., productivity, development, security)
   • Support multiple registry sources (official + community registries)

2. Component Marketplace:

   • Create a GitHub repository for community-contributed components
   • Automated CI/CD for component validation and publishing
   • Security scanning and signing in the publishing pipeline
   • Badge system for verified/signed components

3. Discovery Improvements:

   • Add wassette component search <query> CLI command
   • Filter by capabilities (e.g., "show components requiring network access")
   • Version compatibility checking with Wassette runtime
   • Dependency graph visualization for complex components

---

5. Developer Experience & Ecosystem Growth

Language Support Matrix:
Current documentation covers:

• ✅ JavaScript/TypeScript (componentize-js)
• ✅ Rust (cargo-component)
• ✅ Python (componentize-py)
• ✅ Go (TinyGo with WASI)

Emerging Languages:

• C#/.NET - dotnet new wasiconsoleapp (Experimental)
• Java - TeaVM, Bytecoder (Limited WASI support)
• Kotlin - Experimental Wasm target

Recommendations:

1. Expand Language Guides:

   • Add C# guide (especially relevant for Microsoft ecosystem)
   • Document limitations and workarounds for each language
   • Create template repositories for quickstart

2. Tooling Integration:

   • VS Code extension for Wassette development
   • Debugging support for Wasm components
   • Local testing harness before publishing

3. Example Library:

   • Expand examples/ directory with more use cases
   • Add real-world scenarios (data processing, API integrations, etc.)
   • Create tutorial series (beginner → advanced)

---

Key Trends & Strategic Insights

1. MCP is becoming the standard for AI agent integration

Microsoft, Anthropic, and other major players are standardizing on MCP. Wassette's position as an MCP server with WebAssembly capabilities is strategically valuable.

2. Security is paramount in AI agent ecosystems

As AI agents gain more capabilities, the attack surface expands. Wassette's sandboxing approach addresses a critical need.

3. OCI is the universal distribution format

From containers to Helm charts to AI models, OCI registries are becoming the standard. Aligning Wassette with OCI best practices ensures compatibility.

4. Developer experience drives adoption

Projects with excellent documentation, clear examples, and smooth onboarding grow faster. Wassette's recent cookbook additions are a step in the right direction.

---

Recommendations Summary

High Priority

1. ✅ Component signature verification - Critical for production security
2. ✅ MCP ecosystem visibility - Publish to directories, create integration examples
3. ✅ Enhanced component registry - Add versioning, search, and categories

Medium Priority

4. ⚡ C# language support - High value for Microsoft ecosystem
5. ⚡ Private registry authentication - Required for enterprise adoption
6. ⚡ VS Code extension - Improve developer experience

Low Priority (Future)

7. 📅 Component marketplace - Community-driven growth
8. 📅 MCP resources/prompts - Advanced MCP features
9. 📅 Registry mirroring - Offline scenarios

---

Key Sources

• Azure Container Registry Security Best Practices
• WebAssembly Security Considerations
• Model Context Protocol Overview
• OCI Distribution Specification v1.1
• Notary Project for Artifact Signing
• Azure Sandbox Security Guidance

---

Suggested Next Steps

1. Immediate Actions:

   • Review and prioritize signature verification implementation
   • Draft MCP ecosystem visibility plan (blog posts, integration examples)
   • Gather requirements for enhanced component registry features

2. Documentation Updates:

   • Add security best practices guide for component authors
   • Create deployment guide for enterprise environments
   • Document OCI registry setup and configuration

3. Community Engagement:

   • Announce Wassette in MCP community channels
   • Create sample components for common use cases
   • Start discussions on component registry enhancement

4. Technical Investigation:

   • Evaluate Notation integration complexity
   • Prototype enhanced registry metadata structure
   • Assess C# Wasm component support maturity

---

Note: This research focused on ecosystem alignment, security best practices, and strategic positioning. For specific technical implementation questions, additional targeted research would be beneficial.

AI generated by Scout

[Mossaka]

/scout can you do some research on the topices of "Wassette should be configured in a way to trust a set of tools from a specific criteria. For example, I trust all "the microsoft/... tools". Need some research on what the UX would look like that builds on top of the wassette experience today."?

Agentic Scout triggered by this comment

[github-actions]

🔍 Scout Research Report

Triggered by @Mossaka

Executive Summary

The request is to enable trust-based component configuration in Wassette, allowing users to trust tools based on organizational namespace criteria (e.g., "trust all microsoft/* tools"). Based on my analysis of Wassette's current architecture and industry patterns, I've identified several UX approaches that build naturally on the existing permission and policy system.

Key Finding: Wassette already has the foundation for trust-based configuration through its per-component policy system. The enhancement requires adding namespace/organization-level trust policies that cascade to individual components.

Click to expand detailed findings

Current Wassette Architecture Context

Existing Permission System

Wassette implements a deny-by-default security model with:

• Per-component policies: Each component has independent {component_id}.policy.yaml files
• Fine-grained permissions: Storage (filesystem), network (hosts), environment variables, and memory
• Runtime enforcement: WebAssembly sandbox blocks unauthorized access
• Built-in tools: grant-*-permission, revoke-*-permission, reset-permission, get-policy

Component Loading Flow

1. Components loaded via OCI registries (`(redacted)) or local files
2. Registry format already captures organization namespace (e.g., ghcr.io/microsoft/fetch-rs)
3. Component metadata includes URI, name, and description
4. Policies stored co-located with components in $XDG_DATA_HOME/wassette/components/

Research Findings: Trust Models in Package Ecosystems

1. NPM Scoped Packages Model

Pattern: @organization/package-name

Trust mechanisms:

• Organizations create verified scopes (e.g., @microsoft/, @azure/)
• Users can configure registry preferences per scope
• Automation can apply policies to all packages under a scope
• .npmrc configuration: `@microsoft:registry=(redacted)

Relevance to Wassette: Direct parallel to OCI registry namespaces like ghcr.io/microsoft/*

2. Maven Group IDs

Pattern: com.microsoft.azure:artifact-name

Trust mechanisms:

• Reverse domain notation establishes organizational ownership
• Repository managers (Nexus, Artifactory) can enforce policies per group
• Organizations publish parent POMs that cascade security settings
• Trust decisions based on group ID prefix matching

Relevance to Wassette: Similar hierarchical namespace structure suitable for trust policies

3. Go Modules with vanity URLs

Pattern: github.com/microsoft/tool

Trust mechanisms:

• Repository-based trust (GitHub verified organizations)
• go.mod can specify minimum versions and checksums
• GOPROXY can filter by module path patterns
• Organizations maintain module indexes

Relevance to Wassette: OCI registries already use similar URL-based naming

4. Docker/OCI Registry Trust

Pattern: registry.io/organization/image:tag

Trust mechanisms:

• Content Trust (Notary): Cryptographic signing of images
• Registry allowlists: Organizations maintain approved registries
• Namespace policies: Trust all images from verified publishers
• Image scanning: Automated vulnerability checks before deployment

Relevance to Wassette: Wassette uses OCI registries directly - most applicable model

5. Browser Security and Content Security Policy (CSP)

Pattern: CSP directives for trusted sources

Trust mechanisms:

• `script-src 'self' (redacted) Allow scripts from specific origins
• Wildcards: `(redacted) for subdomain trust
• Nonces and hashes for inline content
• Report-only mode for testing policies

Relevance to Wassette: Demonstrates user-friendly domain-based trust patterns

Proposed UX Approaches

Option 1: Trust Configuration File (Recommended)

Location: ~/.config/wassette/trust.yaml or alongside config.toml

version: "1.0"
trust_policies:
  # Trust all Microsoft tools from GitHub Container Registry
  - pattern: "(redacted)"
    description: "Official Microsoft WebAssembly tools"
    auto_grant:
      - storage:
          allow:
            - uri: "(redacted)"
              access: ["read", "write"]
      - network:
          allow:
            - host: "*.microsoft.com"
            - host: "*.azure.com"
    prompt: false  # Auto-approve without prompt
    
  # Trust verified GitHub orgs with prompt
  - pattern: "(redacted)"
    description: "GitHub verified organizations"
    auto_grant:
      - storage:
          allow:
            - uri: "(redacted)"
              access: ["read"]
    prompt: true  # Prompt before first use
    
  # Untrusted - require manual approval
  - pattern: "(redacted)"
    description: "Default policy for all other components"
    auto_grant: []
    prompt: true

UX Flow:

1. User configures trust policies in trust.yaml
2. When loading `(redacted)
   • Wassette matches against `(redacted) pattern
   • Automatically grants configured permissions
   • Skips prompt (if prompt: false)
   • Logs trust decision for audit
3. User can override with --no-trust flag: `wassette component load --no-trust (redacted)

CLI Commands:

# Add a trust policy
wassette trust add "(redacted)" --auto-grant storage:workspace:rw,network:*.microsoft.com

# List trust policies
wassette trust list

# Remove a trust policy
wassette trust remove "(redacted)"

# Test what permissions a component would receive
wassette trust check (redacted)

Option 2: Interactive Trust Prompts (User-Friendly)

UX Flow: When loading a component for the first time:

$ wassette component load (redacted)

🔒 Trust Decision Required
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Component: fetch-rs
Publisher: microsoft
Registry: ghcr.io
Description: HTTP API client for fetching and converting web content

This component requests:
  • Storage: Read/write access to workspace
  • Network: Access to *.microsoft.com

Trust Options:
  [1] Trust this component once
  [2] Trust all microsoft/* components  ⭐
  [3] Trust this specific component permanently
  [4] Deny and exit

Your choice [1-4]: 2

✅ Trust policy created for "(redacted)"
✅ Component loaded successfully

Future microsoft/* components will be automatically trusted.

Benefits:

• Discoverable for new users
• Contextual learning about trust decisions
• Progressive trust building
• Can be disabled with --assume-yes flag for automation

Option 3: MCP Tool Enhancement (AI Agent Integration)

New MCP Tools:

• create-trust-policy: Create namespace-based trust rules
• list-trust-policies: View configured trust policies
• check-component-trust: Verify trust status before loading

UX via AI Agent:

User: "I want to trust all Microsoft tools from GitHub Container Registry"

Agent: *Uses create-trust-policy tool*

Response: "I've configured Wassette to automatically trust all components 
from (redacted) Future Microsoft components will receive 
pre-approved permissions for workspace access and Microsoft domains."

Benefits:

• Natural language configuration
• Integrates with existing MCP workflow
• AI can explain trust implications
• Audit trail of trust decisions

Option 4: Policy Templates (Enterprise-Friendly)

Approach: Pre-defined trust templates for common scenarios

Location: ~/.config/wassette/templates/ or examples/trust-policies/

# microsoft-enterprise.yaml
version: "1.0"
description: "Enterprise trust policy for Microsoft tools"
trust_policies:
  - pattern: "(redacted)"
    auto_grant:
      - storage:
          allow:
            - uri: "(redacted)"
              access: ["read", "write"]
      - network:
          allow:
            - host: "*.microsoft.com"
            - host: "*.azure.com"
            - host: "api.openai.com"  # For Azure OpenAI
    prompt: false

CLI Usage:

# Apply a trust template
wassette trust apply --template microsoft-enterprise

# List available templates
wassette trust templates

# Create custom template from current policies
wassette trust export > my-org-policy.yaml

Recommended Implementation Path

Phase 1: Core Trust Infrastructure (MVP)

1. Trust policy file format: Define YAML schema for trust.yaml
2. Pattern matching: Implement glob/regex matching for OCI URIs
3. Policy lookup: Match loaded components against trust patterns
4. Auto-grant logic: Apply configured permissions automatically
5. Audit logging: Record trust decisions and policy applications

Estimated effort: 2-3 weeks

Phase 2: UX Enhancements

1. CLI commands: wassette trust add/list/remove/check
2. Interactive prompts: Trust decision UI for first-time loads
3. MCP tools: create-trust-policy, list-trust-policies
4. Documentation: User guide and examples

Estimated effort: 1-2 weeks

Phase 3: Advanced Features

1. Policy templates: Pre-defined trust configurations
2. Cryptographic signing: Verify component publishers (OCI Notary integration)
3. Trust levels: Graduated trust (e.g., read-only → read-write)
4. Expiration: Time-limited trust policies
5. Remote policies: Fetch trust configs from organization servers

Estimated effort: 3-4 weeks

Technical Considerations

Pattern Matching Syntax

Recommend glob patterns for simplicity:

• `(redacted) All Microsoft components
• `(redacted) All verified publishers
• `(redacted) All internal registry components
• `(redacted) Wildcard (default policy)

Precedence Rules

When multiple patterns match:

1. Most specific pattern wins: microsoft/fetch-rs > microsoft/* > *
2. Explicit deny overrides allow: Security-first approach
3. Later rules override earlier: Allow policy refinement

Security Guardrails

• Never trust by default: Require explicit trust configuration
• Audit trail: Log all trust decisions with timestamps
• Review prompts: Periodic review of trust policies (e.g., "You have 5 trust policies. Review?")
• Scope limitations: Trust policies cannot grant more than user's own permissions
• Revocation: wassette trust revoke <pattern> removes policies

Integration with Existing Systems

Component Registry (component-registry.json):

• Could annotate components with "verified" status
• Add publisher reputation scores
• Include security scan results

Policy System (policy.yaml):

• Trust policies generate per-component policies
• Component-specific policies can override trust defaults
• Manual grants take precedence over trust policies

Permission Tools:

• grant-*-permission still works for individual components
• Trust policies provide baseline, users can add more
• get-policy shows "trust policy applied" in metadata

Comparison with Existing Security Systems

System	Trust Model	Relevance
npm verified publishers	Organization verification badge	✅ Direct parallel to OCI orgs
Docker Content Trust	Cryptographic signing	🔄 Future enhancement
Maven Central verification	PGP signatures + metadata	🔄 OCI registries support signing
Browser CSP	Origin-based trust	✅ Pattern matching applicable
iOS App Store	App review + sandboxing	✅ Similar pre-approval model
Chrome Extensions	Permission manifests + review	✅ Combines trust + capabilities

User Personas and Use Cases

Persona 1: Enterprise Developer

Need: Trust all internal tools from corporate registry

trust_policies:
  - pattern: "(redacted)"
    auto_grant:
      - storage: { allow: [{ uri: "(redacted)", access: ["read", "write"] }] }
      - network: { allow: [{ host: "*.company.com" }] }
    prompt: false

Persona 2: Open Source Contributor

Need: Trust specific orgs but review new tools

trust_policies:
  - pattern: "(redacted)"
    prompt: true  # Review first time, then remember
  - pattern: "(redacted)"
    prompt: true

Persona 3: Security-Conscious User

Need: Manual approval for everything

trust_policies:
  - pattern: "(redacted)"
    auto_grant: []
    prompt: true  # Always prompt

Recommendations

For Initial Release (MVP)

1. Implement Option 1 (Trust Configuration File) as the foundation
2. Add CLI commands for managing trust policies (wassette trust)
3. Basic pattern matching with glob syntax
4. Audit logging of all trust decisions
5. Clear documentation with examples for common scenarios

Future Enhancements

1. Interactive prompts (Option 2) for better discoverability
2. MCP tool integration (Option 3) for AI agent support
3. Policy templates (Option 4) for enterprise adoption
4. Cryptographic verification via OCI Notary/Sigstore
5. Web UI for visual policy management

Documentation Needs

1. Trust configuration guide: How to set up trust policies
2. Security best practices: When and how to trust components
3. Policy examples: Common patterns for different organizations
4. Migration guide: Moving from manual grants to trust policies
5. Troubleshooting: Common trust configuration issues

Key Sources

• Wassette Documentation:

  • Permission System Design
  • CLI Reference
  • Architecture Overview

• WebAssembly Security:

  • WebAssembly Security (W3C)
  • Wasmtime Security
  • WASI Component Model

• Package Manager Trust Models:

  • NPM Package Provenance
  • Docker Content Trust
  • Maven Central Publisher Verification

• Browser Security Models:

  • Content Security Policy (MDN)
  • Chrome Extension Security

Suggested Next Steps

1. Gather community feedback on proposed UX approaches (create RFC issue)
2. Define trust policy schema (trust.yaml format)
3. Implement pattern matching for OCI URI patterns
4. Prototype CLI commands (wassette trust add/list/remove)
5. Create example configurations for Microsoft tools, ByteCodeAlliance, etc.
6. Write user documentation with common trust scenarios
7. Add integration tests for trust policy application
8. Consider security review of trust model implementation

---

Summary: The most practical approach is to implement a trust.yaml configuration file with glob-pattern matching for OCI URIs (e.g., (redacted)), combined with CLI tools (wassette trust`) and clear documentation. This builds naturally on Wassette's existing per-component policy system while providing the namespace-level trust functionality requested.

The trust policies would automatically grant pre-configured permissions when components matching the patterns are loaded, with optional prompts for user confirmation. This provides flexibility for different security postures (enterprise auto-trust vs. security-conscious manual review) while maintaining Wassette's deny-by-default security model.

AI generated by Scout