Plugins
Understand plugins as governed extension points for request-aware, response-aware, and evidence-aware gateway behavior.
Plugins
Plugins are modular extension points in the Odock gateway lifecycle. They add custom checks, transformations, integrations, and evidence collection around LLM and MCP traffic without changing application calls.
Use plugins for organisation-, tenant-, workflow-, or toolchain-specific behavior: audit export, request enrichment, tenant checks, approvals, DLP integrations, custom headers, enterprise policy integrations, analytics, webhooks, email notifications, and context-aware recommendations.
Plugins sit near runtime traffic. Scope them tightly, make them observable, enable them explicitly, and place them only where the required context exists.
Why Plugins Exist
Odock already has first-class controls for common AI governance problems:
- Virtual API Keys authenticate callers and provide runtime attribution.
- Models & MCP define the resources applications can call.
- Security & Guardrails enforce policy limits, access, request limits, MCP rules, SafetySec, and cost boundaries.
- Budgets and Quotas enforce spend and usage ceilings.
- Usage Monitoring records what happened.
Plugins cover work too deployment-specific for a universal product control. Use them to integrate with your approval system, SIEM, DLP provider, classification service, email workflow, analytics warehouse, or business logic.
What Plugins Are
A plugin is a named unit of behavior that runs at one or more lifecycle moments. Depending on its purpose and permissions, it can:
- allow traffic to continue
- block traffic with a user-visible reason
- transform allowed request or response fields
- add metadata or headers
- call an external system through a governed integration
- emit audit, analytics, or operational evidence
- run follow-up work after the caller has received the response
A plugin is not an escape hatch around Odock governance. Design it with least privilege, explicit configuration, stable audit evidence, and clear user-visible behavior.
When To Use Plugins
Use a plugin for business-, integration-, or workflow-specific requirements.
| Need | Use |
|---|---|
| Export selected request decisions to a SIEM or audit archive. | Plugin |
| Add tenant metadata, trace headers, or custom billing tags before upstream work. | Plugin |
| Consult an enterprise approval system for sensitive model use. | Plugin |
| Send webhooks, email, or analytics events after a response. | Plugin |
| Recommend an internal offer or workflow based on conversation signals. | Plugin |
| Branch on request content, route by tier, or chain several conditional steps together. | Flow Studio |
| Enforce requests per minute, request bytes, token windows, or concurrency. | Guardrail policy or ratelimit module |
| Detect prompt injection, unsafe output, leakage, or redaction needs. | SafetySec |
| Decide whether an API key can call a model or MCP server. | Access grant |
| Stop spend or usage after a period limit is reached. | Budget or quota |
How Plugins Differ From Other Controls
Plugins work beside guardrails, SafetySec, budgets, quotas, and access grants. They do not replace them.
| Control | Primary question | Typical owner |
|---|---|---|
| Access grants | Can this virtual API key call this model or MCP server? | Operator |
| Guardrail policies | Does this traffic satisfy configured runtime limits? | Operator |
| Ratelimit modules | Is the traffic shape acceptable right now? | Odock runtime policy |
| SafetySec modules | Is the prompt or response safe according to security rules? | Security operator |
| Budgets | Would this exceed a spend boundary? | Finance or platform operator |
| Quotas | Would this exceed a usage boundary? | Platform operator |
| Plugins | Does this deployment need custom workflow, integration, transformation, or evidence? | Deployment owner with Odock review |
For the broader security model, start with Security & Guardrails. For prompt and response safety, see SafetySec. For MCP-specific tool risk, see MCP Security.
Plugin Design Philosophy
Odock plugin design follows these principles.
| Principle | Meaning |
|---|---|
| Modularity | A plugin should solve one clear problem and be replaceable without changing application code. |
| Least privilege | A plugin should receive only the capabilities, lifecycle moments, and data it needs. |
| Lifecycle placement | A plugin should run where the required context exists, not earlier. |
| Composability | Multiple plugins should be able to contribute independent decisions or evidence without becoming one large custom subsystem. |
| Observability | Operators should understand what the plugin allowed, blocked, transformed, emitted, or recorded. |
| Deployment-specific behavior | Plugins can express behavior that belongs to a customer, tenant, environment, vendor, or private integration. |
Contact Odock when a plugin needs internal implementation details, custom contracts, private deployment setup, or security review. Public documentation covers the operating model, not private gateway wiring.
Section Guide
- Architecture: public-safe architecture, lifecycle gates, least privilege, and observability.
- Plugin Lifecycle: how plugins participate before upstream work, after upstream response, and after response or evidence collection.
- Execution Lanes: how plugins and flows at the same lifecycle moment are grouped into sequential, parallel, and async lanes.
- Flow Studio: the visual and YAML automation builder for conditional, multi-step behavior across the same lifecycle moments.
- Marketplace: coming-soon marketplace concept for discovering, publishing, selling, reviewing, and enabling plugins.
- Evaluate A Plugin: checklist for deciding whether to enable a plugin.
- Request A Custom Plugin: current public-safe process for requesting custom plugin work from Odock.