Deployment

Architecture

PlainID Edge extends PlainID Authorization and governance capabilities into your Kubernetes environment. It enables:

• Runtime authorization enforcement for MCP-based tools and services
• Discovery of vector databases, MCP services, tools, and metadata
• RAG enrichment and classification of vectorized data
• Policy-driven filtering and governance of AI-driven workflows

The deployment is centered around the Core Helm Chart, which installs and orchestrates the primary Edge services as a single, cohesive stack.

Deployment Flow

Below is the PlainID Deployment Flow.

1. Provision Kubernetes cluster.

2. Obtain access to PlainID Helm OCI registry and container images.

3. Prepare a Helm values file:

   • Configure PlainID endpoints and credentials
     • See About Scopes for more information on how to extract credentials (clientId and clientSecret)
   • Define Pinecone or MCP sources
   • Configure enrichment and classification settings
   • Provide required secrets

4. Install the core Helm chart.

5. Validate:

   • Health endpoints
   • MCP connectivity
   • Discovery execution
   • Enrichment results

Read more below to understand how the core components work in the deployment flow.

Core Components

The core chart installs the foundational Edge services required for the PlainID Edge deployment.

The guide walks through authenticating to the PlainID OCI Helm registry, validating chart access, and deploying the core chart with a custom values file. Each component within the chart can be enabled or disabled independently through Helm values, allowing the deployment to be tailored to specific operational requirements.

For the full deployment procedure and configuration details, see the Core Helm Chart documentation

Docker Compose

The Docker Compose article explains how to deploy PlainID Edge using a Docker Compose–based configuration. The deployment installs the core Edge services required to support MCP Gateway operations, Discovery, and optional RAG enrichment capabilities.

The guide covers cloning the example repository, configuring the required service environment variables and configuration files, and starting the Edge stack using Docker Compose. The provided recipe serves as a reference deployment and can be adapted to meet specific infrastructure or operational requirements.

For the full deployment procedure and configuration details, see the Docker Compose article.

MCP Gateway

The MCP Gateway acts as the Runtime orchestration and enforcement layer. This gateway:

• Routes requests to one or more backend MCP servers
• Forwards only explicitly allowed headers
• Integrates with PlainID Runtime for fine-grained authorization
• Enforces policy decisions at request time
• Supports OAuth and secure backend connectivity

The MCP Gateway is the primary enforcement point for tool and resource access.

For configuration details, see: MCP Gateway.

Enrichment Agent

The Enrichment Agent enriches vector store entries with classification metadata. This agent:

• Invokes an external classification service
• Writes classification results back to the vector store (like Pinecone)
• Supports scheduled or on-demand enrichment

Enriched metadata enables fine-grained authorization and governance of vectorized data.

For configuration details, see Enrichment Agent.

Vector DB Classifier Engine

The Vector DB Classifier Engine performs vector ingestion and classification. This engine:

• Uses machine learning models for classification
• Generates embeddings (requires OPENAI_API_KEY)
  • Currently, only the Open AI API Key is supported. If using a different type of credentials, contact PlainID Support.
• Produces candidate metadata filters for governance
• Supports autoscaling and production-grade deployment patterns

This component typically serves as the classification backend used by the Enrichment Agent.

For configuration details, see Vector DB Engine.

Discovery Agent

The Discovery Agent identifies and reports discoverable assets to the PlainID Cloud platform.

It supports:

• Pinecone discovery (indexes, namespaces, metadata keys, type inference)
• PlainID MCP Gateway discovery (services, tools, connectors)
• Regex-based filtering of namespaces and metadata
• Scheduled discovery using Cron expressions
• Secure communication with the PlainID API and orchestrator

Discovery ensures that Authorization Policies can be applied to real, up-to-date assets.

For configuration details, see Discovery Agent.

Deployment Model

Kubernetes-Based Installation

PlainID Edge is deployed using Helm into an existing Kubernetes cluster. The core chart acts as an umbrella chart that:

• Deploys all required services
• Manages inter-service connectivity
• Centralizes Environment Variables and secret configuration
• Supports global values shared across sub-charts

You may disable any individual component if your architecture requires only a subset of capabilities.

For step-by-step installation instructions, see Core Helm Chart.

Integration with PlainID Cloud

Several Edge components require connectivity to PlainID Cloud services:

• PlainID Runtime API (authorization decisions)
• PlainID API (JWT acquisition)
• PlainID Discovery Orchestrator

Client credentials (clientId / clientSecret) must be provisioned in advance and stored securely using Kubernetes Secrets or Helm secret values. These values can be extracted through the Scopes page. The Runtime and Discovery URLs are available in the Core Helm Chart article.

External Dependencies

Depending on your use case, the deployment may require:

• Pinecone (or other supported vector databases)
• OpenAI API key (for embedding generation in the classifier engine)
• External classification services
• OAuth providers (optional)

All sensitive values must be managed as Kubernetes Secrets and must not be committed to source control.

Operational Considerations

Scheduling

Both Discovery and Enrichment support Cron-based scheduling using a six-field format, including seconds. Scheduled execution enables periodic metadata discovery and recurring enrichment of vector stores.

Security

The MCP Gateway forwards only explicitly defined headers. Secrets such as API keys and client credentials must be injected securely using Kubernetes mechanisms. JWT validation can be enabled where applicable, and network policies and ingress configuration should align with your organization’s security posture.

Scalability

All components support horizontal scaling through replica configuration or HPA, resource requests and limits, production-grade ingress configuration, and readiness and liveness probes. Scaling strategies should align with workload characteristics such as classification volume, MCP traffic, and discovery scope.