Security Architecture

The WYRE MCP Gateway handles your vendor credentials and routes AI requests across your MSP stack. Here's exactly how we protect them.

Credential Protection

Encryption at Rest

All vendor credentials stored by the gateway are encrypted at rest using industry-standard authenticated encryption. Each record is encrypted with a unique derived key and includes tamper detection — if ciphertext is modified, decryption fails rather than returning corrupted data.

Per-Organization Key Isolation

Encryption keys are derived on a per-scope basis. Your organization's credentials are encrypted with a key that is unique to your organization. There is no shared key pool, and credentials encrypted for one organization cannot be decrypted by another — isolation is cryptographic, not just access-control-based.

Credential Scoping

The gateway supports multiple credential tiers to match how MSPs actually work:

Each tier has independent encryption key derivation and database-level uniqueness constraints preventing cross-scope credential access.

Authentication

• OAuth 2.1 with PKCE — users authenticate through a managed identity provider. The gateway never sees, handles, or stores passwords.
• Session integrity — sessions use signed, httpOnly cookies. PKCE state is stored server-side to prevent interception.
• Vendor auth independence — each vendor connection authenticates through the vendor's own API mechanism. The gateway stores these credentials encrypted and injects them into outbound requests at call time only.
• Service client auth — machine-to-machine clients authenticate via client credentials flow with hashed secrets.

Data Flow

Pass-Through Architecture

The gateway operates as a pass-through proxy. Vendor API responses are streamed directly to the requesting AI session. The gateway does not persist, index, cache, or log the content of vendor responses.

Your AI ──▶ WYRE Gateway ──▶ Vendor API (Autotask, Datto, etc.)
               │                    │
               │  Credentials       │  Credentials injected
               │  encrypted at      │  per-request from
               │  rest              │  encrypted store
               │                    │
               ◀────────────────────┘
          Response streamed back
          (inspected for injection, not stored)

What Is Logged

Prompt Injection Defense

When AI agents interact with external APIs, there's a risk that vendor responses could contain text designed to manipulate the AI's behavior. The gateway includes two layers of defense:

Response Inspection

Every tool result returned by a vendor is scanned for known injection patterns before it reaches the AI. Detected content is automatically replaced with a safe placeholder and the event is logged for audit. The AI never sees the original malicious content.

Tool Description Sanitization

Tool definitions from vendor MCP servers are sanitized when they are first cached by the gateway. Control characters are stripped, descriptions are length-limited, and injection patterns in tool metadata are neutralized before they can influence AI behavior.

Multi-Tenancy

The gateway is multi-tenant by design. Isolation between organizations is enforced at multiple layers:

• Cryptographic credential isolation — per-org key derivation ensures one tenant's credentials cannot be decrypted by another, even with direct database access.
• Database-level constraints — uniqueness constraints prevent credential cross-referencing between scopes.
• Session scoping — authenticated sessions are bound to specific user identities; organization context is resolved per-request.
• Request-level credential injection — vendor credentials are resolved and injected per-request based on the authenticated caller's scope. There is no shared credential context between concurrent requests from different organizations.

Network Security

• Vendor communication — vendor API requests are made over encrypted channels (TLS 1.2+). Internal vendor containers communicate within an isolated network environment.
• Egress control — outbound traffic originates from a known, fixed IP range, making it straightforward for vendors that require IP allowlisting.
• No inbound access to vendor containers — internal vendor services are not exposed to the public internet. Only the gateway's authenticated API surface is internet-facing.

Access Controls & Audit

• Role-based access — organizations support owner, admin, and member roles with scoped permissions.
• Credential lifecycle logging — store, retrieve, and delete events are logged with scope and actor information.
• OAuth event logging — login, token exchange, refresh, and session events are captured.
• Rate limiting — request throttling and registration limits prevent brute-force and abuse scenarios.

What We Don't Do

• We don't store vendor API responses or your customer data.
• We don't log the content of tool calls — only metadata.
• We don't share credentials between organizations.
• We don't have a backdoor to view all credentials — decryption requires the scope-specific derived key.
• We don't handle user passwords — authentication is delegated to a managed identity provider.

Questions?

If you have specific security questions not covered here, reach out at [email protected]. We're happy to discuss architecture details, provide additional documentation, or arrange a security review call.