SECURITY & TRUST
Security at Conduit
The plain-language version of how Conduit is built and operated, written for the person running a vendor security review. Where something is not yet true—a certification, a formal target—this page says so instead of implying it.
01Architecture: a pass-through credential proxy
Conduit connects MCP-capable AI clients to the vendor tools an MSP already runs. Your vendor credentials are stored encrypted; when your AI calls a tool, Conduit authenticates the request, decrypts the relevant credential server-side, makes the upstream vendor call, and returns the response. Credentials are never transmitted to the AI model or to the end user’s workstation—the MCP protocol carries only the tool name, arguments, and result.
What Conduit stores: account information, encrypted vendor credentials, and audit/request logs. What it does not: your card data (Stripe-held), your AI conversations (never visible to Conduit), or a warehouse of your vendor data (requests are proxied in real time).
Static egress IP
20.242.40.128 Outbound calls from Conduit to vendor APIs leave from this single static IP. Add it to firewall rules and vendor API allowlists—IT Glue and similar—so those calls are permitted.
02The trust model, honestly
The question sophisticated buyers ask is: if the operator of Conduit is compromised, what is my exposure? Conduit decrypts secrets in-process to proxy your API calls, so the operator—you if self-hosted, WYRE if WYRE-managed—holds the trust dependency. With production access plus a database export, an operator could in principle decrypt credentials offline. This is a property of any service that handles your secrets to make API calls on your behalf, and we will not claim otherwise.
What matters is that the dependency is bounded (per-record key derivation means no free mass dump; there is no admin view-credential page, no support-tier reset path, no export script—adding one would be visible in git history), observable (every tool call hits the audit log within seconds; infrastructure access lands in cloud provider activity logs; credential-path code changes go through review), and reversible (rotate the credential at the vendor and what Conduit holds goes stale instantly; deletion erases the encrypted record immediately).
What we won't claim: that staff cannot decrypt your data, that the master key is hardware-secured, that Conduit is zero-knowledge, or any certification we have not earned. The single biggest planned improvement—envelope encryption with an HSM-backed key-encryption key that cannot be extracted, only used—is in flight and described in the security reference.
03Certifications: what we hold and what we don’t
| Framework | Status | Notes |
|---|---|---|
| SOC 2 | Not certified | Controls are monitored continuously by Vanta—the live view is our trust center. We’ll claim it when we earn it. |
| ISO 27001 | Not held | Not currently pursuing. We say so rather than implying coverage. |
| HIPAA | Not offered | We do not sign Business Associate Agreements today. |
| PCI DSS | Not applicable | Card data never touches Conduit—payment processing is handled entirely by Stripe. We store only the Stripe customer ID and subscription state. |
| CMMC | Not certified | Not currently pursuing. |
04Encryption
Vendor credentials are encrypted with AES-256-GCM using per-record key derivation: PBKDF2-SHA512 at 100,000 iterations, seeded with a per-record 32-byte salt and a scope-binding string, so each record’s key is independent and credentials encrypted for one scope cannot be decrypted with another’s context. Encryption happens at the application layer—the database stores only ciphertext. OAuth tokens for browser-OAuth vendors are protected the same way. All transit is TLS.
05Authentication
Users authenticate via Auth0 OIDC or Microsoft Entra ID. AI clients authenticate via OAuth 2.1 with PKCE (S256 only), with RFC 8414 metadata published at the standard well-known endpoints. Access tokens are short-lived JWTs; refresh tokens rotate on every use, making theft both narrow in window and detectable on concurrent reuse. Invitation tokens are stored hashed with rate-limited issue and acceptance.
06Tenant isolation
Every record is scoped to an organization ID and enforced with Postgres Row-Level Security—predicates written as reviewable SECURITY DEFINER functions, WITH CHECK clauses on writes—evaluated by the database on every query no matter how the application constructs it. Credentials are additionally encrypted under organization-scoped keys. The reseller hierarchy is bounded to depth 3 with scoped, transitive administration. Vendor MCP containers live on an internal network behind Conduit’s auth layer, never directly exposed.
07AI-specific security
Conduit sees tool calls, never your conversation. Prompt injection is met structurally—typed tool_result envelopes, content-type tagging, namespaced privileged tools that allowlists can fence off—and operationally with least-privilege guidance. An alpha, observation-only threat-scanning layer can watch for stolen-credential signals and injection-style exfiltration, storing metadata only, never flagged content. We label it alpha because it is.
MYTHS VS. REALITY
08What MCP security skeptics get wrong (and right)
Myth: “MCP has no authentication.”
Conduit’s MCP endpoint requires OAuth 2.1 with PKCE—S256 only—with rotating refresh tokens and published RFC 8414 metadata. Local unauthenticated stdio servers exist in the ecosystem; this is not one.
Myth: “An MCP gateway can read all your business data.”
Conduit proxies the tool calls you make, under allowlists you control, with a deny-by-default posture available from day one. It holds no warehouse of vendor data to read, and it never sees your prompts.
Myth: “The AI could delete everything.”
Only tools your allowlists permit can run, per role. Every call is audit-logged within seconds, and access is revocable instantly—at Conduit or by rotating the credential at the vendor.
Myth: “Credential proxies are zero-knowledge.”
None are—a proxy must decrypt to make your API call, whoever builds it. We publish the honest trust model above instead of the comforting claim.
Myth: “Prompt injection makes AI-tool use unsafe, full stop.”
It is a real, unsolved class of attack—which is why the defenses here are structural (typed results, fenced privileged tools) plus operational (least privilege, audit review), not a claimed silver bullet.
09Audit logging and retention
Every tool call is recorded immutably: user, organization, vendor and tool, UTC timestamp, response status, duration. Administrative actions (membership, credentials, allowlists, invitations, impersonation) land in a separate admin audit log. Request logs are retained 13 months; admin audit logs 90 days by default. Owners and admins can export logs as CSV, and organizations with longer regulatory horizons should stream to their own SIEM.
10Availability and continuity
The commitment is 99.5% monthly availability, measured at the externally-facing endpoints, with service credits as the remedy—basis and caveats published in the SLA. Live component and per-vendor health is on the status page. Formal RTO/RPO targets are not yet published; the database runs on Azure Database for PostgreSQL with provider-managed backups.
11Subprocessors
The canonical list—who, where, why, and what data—is at conduit.wyre.ai/subprocessors, kept in lockstep with the codebase: adding an integration in code means adding a row in the same PR. We notify account contacts before a new subprocessor processes customer data; subscribe at the trust center for advance notice. Vendors you connect with your own credentials are your processors, not ours—the distinction is spelled out on that page.
12Responsible disclosure
Found a vulnerability? Email [email protected]—machine-readable details are at /.well-known/security.txt. Safe harbor: we will not pursue legal action against good-faith security research that respects user privacy, avoids service disruption, and gives us reasonable time to remediate before public disclosure. Tell us what you found and how to reproduce it; we will acknowledge receipt, keep you informed, and credit you if you want credit.
DUE-DILIGENCE ANSWER BANK
13Your security questionnaire, pre-answered
The questions security questionnaires actually ask, answered here so your review can start before you send the DDQ. Need these in your own format (SIG, CAIQ)? Submit your questionnaire through our trust center or send it to [email protected].
How are vendor credentials protected at rest?
Encrypted with AES-256-GCM using per-record key derivation (PBKDF2-SHA512, 100,000 iterations, per-record 32-byte salt, scope-binding string), at the application layer before they reach the database. A database breach exposes ciphertext, not plaintext. The implementation is a ~100-line self-contained module and we are happy to walk through it on a call.
What protects data in transit?
TLS everywhere. Public traffic terminates at the Cloudflare edge over TLS; the MCP protocol between AI clients and Conduit runs over HTTPS.
Who holds the encryption keys? Is the master key in an HSM?
The operator of the deployment holds the master key, which today lives in a cloud secret, not a hardware module—we will not claim otherwise. The planned improvement is envelope encryption with an HSM-backed key-encryption key that has wrap/unwrap permission only, moving the trust boundary from people with production access to code running in the operator’s managed-identity context.
How do users authenticate?
Via Auth0 OIDC, or Microsoft Entra ID for organizations signing in with Microsoft. Organization invitation tokens are stored hashed, with rate-limited creation and acceptance paths.
How do AI clients authenticate?
OAuth 2.1 with PKCE—S256 only, plaintext challenges are rejected—with RFC 8414 metadata published at /.well-known/oauth-authorization-server. Access tokens are short-lived JWTs; refresh tokens rotate on every use, so a stolen refresh token has a narrow window and concurrent reuse is detectable.
Do you support SSO and SCIM provisioning?
Yes—users and teams can be auto-provisioned from Entra ID, Okta, JumpCloud, or Google Workspace via SCIM. See the SCIM guide.
What roles and permissions exist?
Organization roles are owner, admin, and member, plus reseller-scope roles for the subtenant hierarchy. Tool allowlists restrict which tools each role can call; we recommend new organizations start deny-by-default and grant vendor access explicitly.
Can destructive or sensitive tools be restricted?
Yes. Privileged tools (for example password retrieval in documentation platforms) are namespaced and can be limited to specific roles via tool allowlists, shrinking the blast radius of both operator error and prompt injection.
How is one customer isolated from another?
Every record is scoped to an organization ID and enforced with Postgres Row-Level Security, evaluated by the database on every query regardless of how the application constructs it, with WITH CHECK clauses blocking cross-tenant writes. Credentials are additionally encrypted under organization-scoped derived keys, so blobs are not decryptable across organizations.
Can WYRE staff read my credentials?
We will not claim staff cannot decrypt your data—an operator with production access plus a database export could in principle decrypt credentials offline, as is true of any service that handles your secrets to make API calls for you. What we engineer for is a trust dependency that is bounded (per-record key derivation, no admin view-credential page, no export script), observable (audit log within seconds, reviewed code changes), and reversible (rotate at the vendor and what we hold goes stale instantly). See the trust model above.
How does the reseller hierarchy affect isolation?
The reseller → customer → sub-customer hierarchy is bounded to depth 3. Reseller admins administer their own customers transitively; customer admins reach only their own organization and direct sub-organizations. Reseller pricing configuration is not visible to sub-customers.
Are vendor integrations exposed to the internet?
No. Vendor MCP server containers run on an internal network and are not directly reachable; all inbound traffic passes through Conduit’s authentication and authorization layer first.
Can Conduit see my prompts or AI conversations?
No. Conduit receives tool calls, not the chat between you and your model. What you typed, the model’s reasoning, and any message that never became a tool call are never visible to Conduit.
Is my data used to train AI models?
Conduit is not a model provider and does not send your data to any model itself. Your AI client is yours—tool results flow back to it and are processed under your agreement with your AI provider, not ours.
How do you defend against prompt injection?
Structurally: tool responses return as typed tool_result objects rather than raw conversation text, responses are tagged by content type, and privileged credential-retrieval tools are namespaced so allowlists can fence them off. We pair that with least-privilege guidance because prompt injection is not a solved problem anywhere—defense in depth, honestly labeled.
Can you detect stolen credentials or data exfiltration?
Threat scanning—currently an alpha, observation-only feature a reseller admin can enable—watches for agent-identity drift (a credential suddenly presenting from a different client shape) and untrusted content resurfacing in later sensitive calls. Detections store metadata only, never the flagged content, enforced at the write path.
What do you store, and for how long?
Account information, encrypted vendor credentials, and audit/request logs. Vendor API traffic is proxied in real time, not warehoused. Request logs are retained 13 months; admin audit logs 90 days by default. Card data is never stored—billing is Stripe-held.
What happens when I delete a credential or leave?
Deleting a credential erases the encrypted record immediately, and Conduit holds no persistent vendor sessions—rotating the credential at the vendor also kills anything we hold, instantly. Removing a member revokes their access to org credentials with no cached tokens.
Where is my data hosted?
Microsoft Azure, United States (East US 2): Container Apps runtime, Azure Database for PostgreSQL, Key Vault for secrets, Log Analytics for infrastructure logs. The full provider list is on the subprocessors page.
What is your uptime commitment?
Monthly availability at or above 99.5%, measured at the externally-facing endpoints, with service credits as the remedy—the basis, caveats, and response-time matrix are published in the SLA. Live and historical component health is on the status page (also machine-readable at /status.json).
What are your RTO and RPO?
Formal RTO/RPO targets are not yet published—we would rather say that than invent numbers. The database runs on Azure Database for PostgreSQL with provider-managed backups, and incident communication follows the SLA: status page updates plus email to account contacts for significant incidents.
Are you SOC 2 or ISO 27001 certified?
No, and we say so plainly—see the certifications table above. Our controls are continuously monitored by Vanta and published at our trust center; certification claims will appear when they are earned, not before.
Do you offer a DPA or GDPR terms?
Our data-handling commitments are published in the Privacy Policy and the subprocessors list. For data-processing terms, contact [email protected].
Do you sign BAAs / support HIPAA-regulated workloads?
We do not sign Business Associate Agreements today.
Has Conduit been penetration tested?
Penetration-test reports are available under NDA—request via [email protected].
Can you provide certificates of insurance?
Available on request via [email protected].
Who are your subprocessors?
The canonical list—provider, legal entity, location, purpose, and data processed—is at conduit.wyre.ai/subprocessors. We update it before a new subprocessor begins processing customer data; subscribe at the trust center for advance notice.
Are the vendors I connect (PSA, RMM, …) your subprocessors?
No. You connect them with your own credentials and they process data under your agreement with them, not under WYRE’s. Conduit proxies your requests to them at your direction—that distinction is spelled out on the subprocessors page.
How do I report a security vulnerability?
Email [email protected]. Good-faith research is covered by the safe-harbor commitment in the responsible-disclosure section above, and machine-readable contact details are published at /.well-known/security.txt.