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.
How to read this page
Two things carry the Plexara name, and this page keeps them apart. The product is your dedicated deployment and everything Deasil Works runs to operate it. The website is plexara.io, the pages you are reading right now. Every section below names which one it covers, and a statement about one is never a statement about the other.
Last reviewed: August 2026
The Product / 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.
The Product / Data Protection
How customer data is protected
Everything in this section describes your Plexara deployment and the data inside it.
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. A persona has to match the roles your identity provider issued before any surface opens, and personas deny all tool access until a grant says otherwise.
Write control on the catalog
Editing a table description, tag, domain, or glossary term takes two grants at once: the matching tool on the persona, and a connection marked write-enabled. Both are checked on the server whatever the interface offers, and every write lands in the audit log.
Shared files and links
A file your team uploads, saves, or shares opens as the document it is and cannot act on the platform or the session viewing it. Each share link names its audience when it is created, the named recipient or your signed-in users or anyone holding the link, and stops opening when it expires or is revoked.
Notification email
Messages from your deployment are traceable to the domain they were sent from and carry the legal footer links a recipient expects. Unsubscribe works from the button the recipient’s own mail client offers, so an opt-out takes one click and is recorded.
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.
The Product / 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.
The Product / 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.
The Product and the Website / Subprocessors
The product has zero subprocessors
The product: no third party at all
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. Notification email is part of the managed service and adds no vendor to that list.
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.
The website: three vendors, named
plexara.io is a marketing site and processes no customer platform data. It uses Cloudflare for DNS, TLS, and bot protection, Buttondown to deliver the newsletter to people who subscribe, and Google Analytics for consent-based traffic measurement.
None of the three has any access to any Plexara deployment, and none appears in the Data Processing Agreement, which covers the product. The privacy policy covers what the website itself collects.
The Product / Compliance
The compliance roadmap
SOC 2 Type II is on the roadmap for the product. 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:
- The MCP threat catalog, and the control set the product enforces on every request
- How the product authorizes a tool call at the moment it runs, and what it audits
- The US data center facilities a product deployment runs in
- Our vulnerability disclosure policy and RFC 9116 security.txt
- What the website collects, and the consent it asks for first
CSA AI Trustworthy Pledge
Plexara has signed the Cloud Security Alliance AI Trustworthy Pledge, affirming alignment with its core principles of safety, transparency, ethical accountability, and privacy in AI systems. It is a public commitment rather than an audit, and the Cloud Security Alliance names every organization that has taken it.
The listing reads Plexara, the product the pledge covers. Deasil Works, Inc. is the operator of record behind it and the contracting entity on your service agreement and Data Processing Agreement.
Find Plexara on the CSA signatory listThe Product and the Website / AI Security
The AI vendor questionnaire, pre-answered
No. This answer is about the product, your Plexara deployment. 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. This answer is about the product. 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). The tools also publish closed input schemas, so an argument a tool does not define is refused before the tool runs and a steered agent cannot smuggle a parameter past the contract it advertised. Catalog metadata is screened for instruction-like patterns before enrichment, and detections are logged. No vendor can promise to scrub 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). This answer is about the product. A persona is what opens any surface at all: a caller whose roles match no persona reaches nothing, and the persona's connection grants govern what that caller can see as well as what they can call, so a restricted agent does not discover the datasets, connections, and endpoints it is not cleared for. 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. A failure also records its category, so a denied permission, a malformed call, and a platform fault are three distinguishable rows rather than one bucket of errors. 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 pinned per deployment and upgraded on a schedule agreed with you, with advance notice before any maintenance window. The embedding model is pinned too, and every stored vector records the model that produced it, so a later model change is visible rather than silent. Because no external generative model sits in the platform's serving path, a model provider's deprecation or quiet update cannot change your deployment'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 we will state for each answer whether it covers the product or the plexara.io website so your reviewer never has to guess.
No, and the distinction matters when a reviewer scores vendor risk. The product is your dedicated deployment, running on hardware Deasil Works owns and operates, with zero subprocessors. The website is marketing pages, and it uses Cloudflare for DNS, TLS, and bot protection, Buttondown to deliver the newsletter to people who subscribe, and Google Analytics for consent-based traffic measurement. Those three vendors serve the website only. They have no access to any deployment, they process no customer platform data, and they are outside the scope of the Data Processing Agreement.
Whoever the person sharing it chose, and nobody else. Each share link names its audience when it is created: the named recipient, your signed-in users, or anyone holding the link. Open to anyone is always a deliberate selection, never a default, and the link stops opening the moment it expires or is revoked. The file itself opens as the document it is and cannot act on the platform or on the session viewing it, and a response served after a permission check is marked for that one browser so no cache in between can hand it to the next holder of the URL.
Learn more: The control set, in full
Next
Contact
Request a DPA, a vendor security memo, or our SOC 2 readiness status, or send us your security questionnaire.