Plexara
Trust Center
Plexara as a Vendor
The Security page catalogs MCP threats and how the platform architecture answers them. This page is about Deasil Works as a company you would be trusting with data: how your deployment is built and run, what we commit to when something breaks, and the assurances your security team can verify today.
Last reviewed: July 2026
Tenancy and Isolation
Every client gets their own installation
Most SaaS isolation is a customer ID column in a shared database. A Plexara deployment is a separate stack.
01
A dedicated stack
Your deployment runs its own MCP platform, query engine, catalog, identity service, PostgreSQL databases, object store, and embedding model, in its own namespace. No component that stores or processes your data is shared with another customer.
02
No shared control plane
Uptime is a property of your deployment, monitored by its own telemetry and visible in your admin portal. There is no central Plexara service whose outage could reach every customer at once.
03
Owned hardware
Deployments run on servers Deasil Works owns and operates in six US data center facilities. We manage everything from the bare metal up. When something needs inspecting, we can walk the whole stack.
04
The data is yours
Platform data lives in databases provisioned for you. There is no Deasil-owned data layer in the middle, you can bring your own S3-compatible storage, and when a contract ends your data is deleted within 30 days.
Data Protection
How customer data is protected
Encryption in transit
TLS 1.2 or higher on every public endpoint, with certificates automated through cert-manager and Let’s Encrypt on per-client hostnames. Platform connections to PostgreSQL require TLS.
Encryption at rest
Customer data is encrypted at rest with AES-256. Data source credentials get a second layer: AES-256-GCM application-level encryption before they ever reach storage.
Identity and access
Sign-in runs through a dedicated Keycloak identity realm per client over OIDC. Agent connections use OAuth 2.1 with PKCE and short-lived tokens. Personas deny all tool access until a grant says otherwise.
Support access
Deasil staff look at customer data only when you ask for diagnostic or support help. That access is scoped to the request and logged.
Data retention
Customer data is kept for the duration of your service agreement and deleted within 30 days of termination, unless law or a written request from you says otherwise.
Audit trail
Every tool call is recorded with requester identity, persona, authorization decision, outcome, and timestamp. Records stay in your deployment and export to your SIEM.
Backups and Continuity
Backups are part of each deployment
Backup and recovery are configured per installation, not as a platform-wide setting. The baseline:
- Replicated PostgreSQL: a leader and a standby in every deployment.
- Continuous write-ahead-log archiving to object storage.
- Scheduled logical backups on top of the continuous archive.
- Offsite copies, schedules, and retention set in your service agreement.
- Restore procedures are written down and have been used on production deployments.
Incident Response
If something goes wrong, you hear it from us first
Detection comes from per-deployment telemetry and the audit trail. Because every tool call and authorization decision is logged, we can tell you what an incident touched instead of guessing. The engineers who respond are the same people who run the infrastructure; there is no tiered support queue between you and them.
We commit to notifying affected customers within 72 hours of confirming a security incident that involves their data or service, followed by a post-incident summary of cause and remediation.
Security researchers can reach us through the vulnerability disclosure policy, with a machine-readable contact at /.well-known/security.txt.
Subprocessors
The product has zero subprocessors
Your deployment runs start to finish on hardware Deasil Works owns and operates. No third party processes customer platform data. No AI provider receives it either: the platform makes no outbound calls to any model provider, and embeddings are computed inside your deployment.
That is the whole list. There is no external logging service, no third-party analytics, no managed database vendor sitting between you and your data.
Compliance
The compliance roadmap
SOC 2 Type II is on the Plexara roadmap. We share our readiness status and a dated plan with prospective customers on request, and this page will carry the report when the audit completes. In the meantime, the assurances below are stronger than a badge: they are inspectable.
A Data Processing Agreement is available on request. It covers our processor role, your ownership of the data, confirmation that no subprocessor touches customer platform data, 30-day deletion at termination, and the 72-hour notification commitment. A vendor security memo for your security team works the same way: write to [email protected].
What you can verify yourself, today:
AI Security
The AI vendor questionnaire, pre-answered
No. The platform makes no outbound calls to any AI model provider. The only model it runs is a local embedding model (nomic-embed-text on Ollama) that executes inside your deployment on Deasil-operated hardware, so nothing leaves your environment to compute semantic search. Generative reasoning happens in the AI client you choose to connect, such as Claude, under your own agreement with that provider; the major providers exclude commercial API traffic from training by default. Deasil Works does not use your data for training, analytics, or any purpose other than operating your deployment.
With enforcement that lives outside the prompt. Persona authorization, connection allowlists, read-only enforcement, and workflow gates run as server-side middleware before any tool executes, so a poisoned prompt cannot grant an agent access it does not already have (OWASP LLM01). Catalog metadata is additionally screened for instruction-like patterns before enrichment, and detections are logged. What no vendor can honestly promise is scrubbing adversarial language out of legitimate data values, so query results are treated as untrusted content and the defense is bounded blast radius plus a complete audit trail.
Learn more: The full MCP threat catalogEvery tool call is authorized server-side against a fail-closed persona, so an agent can never exceed the calling user's own access (OWASP LLM06, excessive agency). Query connections can be locked to read-only at the platform layer, storage access is restricted by prefix, and the one write path that feeds agent learning back into the catalog requires human review and approval, records a full changeset with a before-image, and supports rollback.
Learn more: Governance at the point of executionEach client runs a dedicated installation: its own MCP platform, query engine, catalog, PostgreSQL databases, identity realm, object storage, and embedding model, in a dedicated namespace on Deasil-operated infrastructure. There is no shared inference service, no shared context store, and no shared control plane, so isolation holds at the context and inference layer, not just the database layer. Within a deployment, memory and session state are scoped per user, and sessions are bound to the authenticating token.
Requester identity, the persona in force, the tool and connection called, parameters with sensitive keys redacted, the authorization decision, outcome, duration, and timestamp, plus session and request identifiers. Records land in your deployment's PostgreSQL store, partitioned monthly with configurable retention, and are exportable to your SIEM. This is the per-decision traceability that EU AI Act Articles 12 and 13 ask deployers to demonstrate.
Platform releases are version-pinned per deployment in versioned manifests and upgraded on a schedule agreed with you, with advance notice for maintenance. The embedding model is pinned in configuration, and every stored vector records the model that produced it. Because no external generative model sits in the platform's serving path, a model provider's deprecation or silent update cannot change your platform's behavior. The model your agents use is whichever AI client you connect, under your control.
Yes. Send it to [email protected]. The answers on this page already use the vocabulary reviewers embed in questionnaires, including the OWASP LLM Top 10 (prompt injection, excessive agency) and the NIST AI RMF govern, map, measure, and manage functions. A formal vendor security memo and a Data Processing Agreement are available on request, and the platform threat model is public in the upstream open source project.
Next
Contact
Request a DPA, a vendor security memo, or our SOC 2 readiness status, or send us your security questionnaire.