[ARCHITECTURE] Identify Next Steps for Plugin Development

[crivetimihai]

Overview

Following the successful implementation of the MVP plugin framework (PR #642), this research ticket aims to identify and prioritize the next steps for expanding the plugin ecosystem. The MVP delivered core functionality with prompt hooks, and now we need to determine which features will provide the most value for users and maintainers.

Current State (MVP Complete)

• ✅ Plugin framework foundation with lifecycle management
• ✅ 2 hook points implemented (prompt pre/post fetch)
• ✅ 3 example plugins (SearchReplace, DenyList, PIIFilter)
• ✅ YAML-based configuration with conditional execution
• ✅ Priority ordering and execution modes

Research Areas to Investigate

Tickets to integrate with plugin system

• [Feature Request]: Tag support with editing and validation across all APIs endpoints and UI [Feature Request]: Tag support with editing and validation across all APIs endpoints and UI (tags) #586

1. Hook System Expansion

• Prompt hooks (prompt_pre_fetch / prompt_post_fetch) ✅ DONE
• Tool hooks (tool_pre_invoke / tool_post_invoke) ✅ DONE
  ➕ CRUD hooks: tool_pre_register / tool_pre_update / tool_pre_unregister
• Resource hooks (resource_pre_fetch / resource_post_fetch)
  ➕ CRUD hooks: resource_pre_create / resource_pre_update / resource_pre_delete
• Server hooks (server_pre_register / server_post_register)
  ➕ CRUD hooks: server_pre_update / server_pre_unregister
  ➕ Attestation on add: server_pre_register will perform server attestation before admission (e.g., verify TLS certificate chain, mTLS/SAN/SPIFFE identity, and—where available—TPM/TEE/cloud instance attestation evidence). Failed checks block registration.
• Auth hooks (auth_pre_check / auth_post_check)
  ➕ CRUD hooks: auth_pre_create / auth_pre_update / auth_pre_delete (for roles, policies, clients/keys, grants)
• Federation hooks (federation_pre_sync / federation_post_sync)
  ➕ CRUD hooks: federation_pre_create / federation_pre_update / federation_pre_delete (remotes, schemas, replication rules)
• Completion hooks for LLM request/response processing (no CRUD—ephemeral)
• Cache hooks for cache manipulation
  ➕ CRUD-like hooks: cache_pre_put / cache_pre_update / cache_pre_evict (plus cache_pre_get / cache_post_get as needed)
• Stream hooks for real-time data processing
  ➕ Lifecycle hooks: stream_pre_open / stream_pre_update / stream_pre_close (subscriptions/channels)
• Error hooks for custom error handling (no CRUD—non-mutating)

Behavioral notes for all pre-CRUD hooks: run after auth passes but before the write; may validate, transform, or veto. A veto aborts the operation with an explicit reason.

Research needed: Which hooks would provide immediate value? Survey users for priority. Initial hypothesis: highest impact are resource_pre_update, server_pre_register (attestation), and auth_pre_update.

1a. Server Attestation & Trust Management (via pre-add hooks)

• Goal: Only admit servers that can prove identity and runtime integrity at registration time.

• Scope of checks (performed during server_pre_register):

  • Certificate and identity verification (TLS chain against configured trust anchors, mTLS policy, SAN/SPIFFE allow-lists, expiry and revocation checks).
  • Optional remote attestation evidence validation (TPM quotes, TEE reports such as SEV-SNP/TDX, or cloud instance attestation like AWS Nitro/GCP/ Azure), including nonce-based freshness to prevent replay.
  • Policy evaluation to map verified claims (e.g., measurement allow-lists, image digests, firmware/kernel versions) to an admit/deny decision.
  • Structured auditing of the decision and evidence metadata.

• Research needed: Common attestation types in target environments; storage/rotation for trust anchors; acceptable verification latency and evidence sizes.

2. Plugin Discovery & Loading

Potential implementations:

• Auto-discovery from plugin_dirs
• Dynamic loading without restart
• Package management integration (pip/poetry)
• Remote plugin loading from URLs/registries
• Plugin manifest validation
• Dependency resolution
• Plugin isolation (separate venvs)
• Lazy loading mechanisms

Research needed: What's the preferred plugin distribution model? Local files vs package registry?

3. Versioning & Compatibility

Potential implementations:

• Version compatibility checks
• Semantic versioning enforcement
• Migration system for configs/data
• Deprecation warnings
• Version constraints (min/max framework)
• Backward compatibility layers
• Plugin upgrade paths
• Rollback capability

Research needed: How critical is backward compatibility? What's the expected update frequency?

4. Configuration & Validation

Potential implementations:

• JSON Schema validation
• Config inheritance with environment overrides
• Secret management (Vault/AWS Secrets)
• Config versioning and history
• Config templates for common use cases
• Config linting tools
• Live config reload
• Backup/restore functionality
• Environment-specific configs
• Config encryption for sensitive data

Research needed: What configuration patterns are most common? Integration priorities?

5. Security & Sandboxing

Potential implementations:

• Plugin sandboxing/isolation
• Permission system (capabilities)
• Resource limits (CPU/memory/network)
• Plugin signing and verification
• Audit logging
• Threat detection
• Network isolation
• File system restrictions
• Secure plugin marketplace
• ➕ Server attestation enforcement at server_pre_register (trust anchors, attestation policy, replay protection, and drift/rotation strategy)

Research needed: What's the threat model? Trust boundaries? Performance impact acceptable?

6. Performance & Monitoring

Potential implementations:

• Metrics collection (Prometheus/OpenTelemetry)
• Performance profiling
• Resource monitoring
• SLA enforcement
• Distributed tracing
• Health check endpoints
• Performance baselines
• Alerting integration
• Dashboard templates
• Capacity planning tools

Research needed: What metrics matter most? Existing monitoring stack to integrate with?

7. Plugin Communication & State

Potential implementations:

• Inter-plugin communication
• Shared state store (Redis/etcd)
• Event bus (pub/sub)
• Plugin pipelines/chains
• Data transformation flows
• State persistence
• Distributed state sync
• Transaction support
• Compensation logic
• Circuit breakers

Research needed: Are plugins independent or do they need to communicate? State requirements?

8. External Integration

Potential implementations:

• LLMGuard completion
• OPA (Open Policy Agent)
• HashiCorp Vault
• Webhook plugins
• gRPC plugins
• GraphQL integration
• Message queues (Kafka/RabbitMQ)
• Database plugins
• Cloud service plugins (AWS/Azure/GCP)
• AI service plugins (OpenAI/Anthropic)
• ➕ SPIFFE/SPIRE for workload identity (optional, to complement server attestation)

Research needed: Which integrations are most requested? Build vs buy decisions?

9. Developer Experience

Potential implementations:

• Plugin CLI tool (mcp-plugin)
• Scaffolding generator
• Testing framework
• Debugger support
• Plugin simulator
• Documentation generator
• Type hints/stubs
• IDE integration
• Examples repository
• Development guide

Research needed: What's the target developer audience? Skill level assumptions?

10. Management & Operations

Potential implementations:

• Plugin API endpoints
• Admin UI
• Marketplace UI
• Role-based access
• Approval workflows
• A/B testing
• Canary deployments
• Feature flags
• Analytics
• Cost tracking

Research needed: Self-service vs managed? UI requirements?

11. Critical Gaps Not Yet Identified

Areas to explore:

• Plugin debugging and troubleshooting tools
• Plugin performance benchmarking suite
• Plugin quality scoring/rating system
• Plugin dependency conflict resolution
• Plugin resource allocation strategies
• Plugin failure recovery mechanisms
• Plugin update notification system
• Plugin telemetry and usage analytics
• Plugin security vulnerability scanning
• Plugin license compliance checking
• Plugin documentation standards
• Plugin testing requirements
• Plugin certification process
• Plugin support model
• Plugin monetization framework (if applicable)

Key Questions to Answer

1. User Priorities: What features do users need most urgently?
2. Use Cases: What are the primary use cases driving plugin adoption?
3. Performance: What performance overhead is acceptable?
4. Security: What security guarantees are required?
5. Scale: How many plugins do we expect in a typical deployment?
6. Distribution: How should plugins be packaged and distributed?
7. Compatibility: How do we handle breaking changes?
8. Support: What level of support can we provide?
9. Community: How do we foster a plugin developer community?
10. Governance: Who decides which plugins are "official"?

Success Metrics to Define

• Plugin adoption rate
• Plugin development velocity
• Plugin reliability (error rates)
• Plugin performance impact
• Developer satisfaction
• Time to develop new plugin
• Plugin marketplace growth
• Community contribution rate
• ➕ % of servers admitted with valid attestation
• ➕ Mean attestation verification latency
• ➕ Attestation failure rate (by reason)

Deliverables from This Research

1. Priority Matrix: Rank features by value vs effort
2. Technical Roadmap: Phased implementation plan
3. Architecture Decisions: Key design choices to make
4. Risk Assessment: Technical and operational risks
5. Resource Requirements: Team/time/infrastructure needs
6. Success Criteria: How we measure progress
7. ➕ Attestation policy and trust anchor strategy (including rotation/drift handling)
8. ➕ Prototype plan for server_pre_register attestation validation

Next Steps

1. Survey current users about plugin needs
2. Analyze similar plugin systems (Jenkins, Grafana, VSCode)
3. Create proof-of-concepts for high-risk items
4. Define plugin developer personas
5. Establish plugin governance model
6. Create technical roadmap based on findings
7. ➕ Define and validate server attestation flow at server_pre_register (cert checks, identity policy, optional remote attestation, audit events)

---

Labels: research, plugins, architecture, roadmap
Assignee: TBD
Milestone: Plugin Framework Phase 2 Planning

[crivetimihai]

TODO:
Add enabled: true or enabled: false in config.yaml for each plugin

[imolloy]

I was looking at my notes, and need to add a few more:

List

For the list calls, such as tools/list, the responses can include poisoning, indirect prompt injection, etc., so we'll need hooks to detect and filter these (similar to InvariantLabs mcp-scan). These are different from the CRUD hooks when adding a new server or tool to the gateway.

• roots_post_list
• prompts_post_list
• tools_post_list 🔨 In Progress
• resource_post_list

Elicitation

Planning for #234

• elicitation_pre_create
• elicitation_post_response

Sampling

• sampling_pre_create
• sampling_post_response

Notifications

Not clear if there is a security issue here or not yet that requires a security hook, but if so...

• changed
• list
• updated

[crivetimihai]

To close this ticket, we should turn it into a fully documented ADR, base on current implementation, this task, and related issues:

• [DESIGN]: Architecture Decisions and Discussions for AI Middleware and Plugin Framework (Enables #319) #313
• [Feature Request]: AI Middleware Integration / Plugin Framework for extensible gateway capabilities #319