Plexara
Architecture
8-Layer Middleware Pipeline
Middleware
The Pipeline
Every MCP request flows through eight independently configurable layers. Each layer can be enabled, disabled, or customized without affecting others.
Layer 1
Description Overrides
Rewrites tool descriptions with workflow guidance, operational requirements, and contextual instructions.
Layer 2
Tool Visibility Filtering
Hides tools the user is not authorized for, reducing LLM token consumption and preventing unauthorized access attempts.
Layer 3
MCP Apps Metadata
Adds UI metadata for the web-based tool exploration interface, enabling auto-generated parameter forms.
Layer 4
Authentication and Authorization
Validates credentials (OIDC, OAuth 2.1, API keys), resolves persona, and enforces tool-level access control.
Layer 5
Audit Logging
Records every tool call with user identity, persona, connection, duration, and success or failure status.
Layer 6
Rule Enforcement
Session-aware workflow gating that tracks whether discovery tools were called before query tools, with configurable escalation thresholds.
Layer 7
Client Logging
Provides structured logging output for MCP client consumption and debugging.
Layer 8
Semantic Enrichment
Intercepts every tool response and enriches it with business context from complementary services. The architectural core of the platform.
Abstraction
Provider Interfaces
Three provider interfaces decouple enrichment logic from specific implementations. The platform can evolve its backing services without changing the enrichment pipeline.
SemanticProvider
Abstracts access to the metadata catalog. Resolves entity URNs, retrieves descriptions, tags, glossary terms, lineage, and quality signals. DataHub is the default implementation.
QueryProvider
Abstracts access to the query engine. Exposes schema information, table availability, and connection routing. Trino is the default implementation.
StorageProvider
Abstracts access to object storage. Manages bucket listing, object retrieval, presigned URLs, and prefix-level access control. S3 is the default implementation.
Security
Fail-Closed by Default
Missing or invalid credentials deny access. No persona assigned means zero tool access. Default-deny posture with explicit allow rules.
Authentication supports OIDC with required JWT claims, OAuth 2.1 with PKCE and Dynamic Client Registration, and API key management for service accounts.
Persona-based authorization maps IdP roles to tool allow and deny patterns with wildcard support. Each tool call is logged with user identity, persona, connection, duration, and outcome.
Supply chain security includes SLSA Level 3 provenance, static analysis with Semgrep and CodeQL, race condition detection, and OpenSSF Scorecard tracking.
Common questions
Architecture FAQ
Plexara composes eight layers between the AI client and your data: MCP transport, authentication and authorization, persona resolution, tool visibility filtering, semantic enrichment, query execution (Trino), metadata catalog (DataHub), and object storage (S3). Each layer is a provider abstraction, so the default implementations are swappable.
Every unauthenticated request, unmapped persona, undefined tool, or unknown data source is rejected by default. There is no anonymous mode, no permissive fallback, no bypass. AI agents only see and call what is explicitly allowed for the authenticated identity behind them.
The Model Context Protocol from Anthropic for the AI-facing surface. Apache Trino for federated SQL across data sources. DataHub for the semantic catalog. S3 for asset storage. None of these are proprietary to Plexara; the platform is the integration and governance work above them.
Trino routes a single SQL query across multiple physical data sources (PostgreSQL, Snowflake, Iceberg, S3, Kafka, and 30+ others) and assembles the result. Agents write standard SQL without knowing where data physically lives. The federation layer handles connector-specific quirks, query optimization, and result composition.
Every tool call is logged with the user identity, the persona under which the call was made, the resolved connection, the tool name, the arguments, and the truncated result. The audit stream is queryable in the portal and exportable to your SIEM. Persona filtering is enforced before the call, not after, so denied calls also appear in the log.
Next
For Data Leaders
TCO reduction, governance, data platform maturity, and vendor independence.