​

Security at Tydli.io

TL;DR: Your API credentials are encrypted with AES-256-GCM, stored server-side only, protected by military-grade access controls, and never touch client-side JavaScript. We’ve built this platform with the same security standards you’d expect from enterprise API management tools.

​

Why Security Matters for MCP Servers

• API credentials (keys, tokens, OAuth secrets)
• Request routing (AI → Your API)
• Authentication flows (OAuth 2.1, JWT, API keys)

​

Core Security Principles

​

1. Zero Trust Architecture

• Every database query is protected by Row-Level Security (RLS) policies
• Users can only access their own deployments, credentials, and logs
• Even our own backend services use the principle of least privilege
• Service role access is logged and audited

• User A cannot view User B’s API credentials
• Leaked database credentials don’t automatically leak user data
• Compromised frontend code cannot bypass backend security

​

2. Defense in Depth

​

Layer 1: Input Validation

• All API requests validated using Zod schemas before processing
• Maximum payload sizes enforced (5MB for OpenAPI specs)
• URL parameters sanitized to prevent injection attacks
• Structured error codes prevent information leakage

​

Layer 2: Authentication & Authorization

• JWT tokens for user sessions (1-hour TTL)
• Email verification required before dashboard access
• Account lockouts after 5 failed login attempts (progressive: 15 min → 1 hour → 24 hours)
• OAuth 2.1 with PKCE for third-party API access

​

Layer 3: Data Protection

• API credentials encrypted with AES-256-GCM before storage
• Encryption keys stored separately from encrypted data
• Credentials never sent to client-side JavaScript
• Dedicated edge function for credential retrieval (rate-limited to 5 requests/minute)

​

Layer 4: Network Security

• All connections use HTTPS/TLS 1.3
• Content Security Policy (CSP) headers enforced
• Security headers (X-Frame-Options, X-Content-Type-Options) enabled
• CORS policies enforced on all edge functions
• Rate limiting at multiple levels (hourly, monthly, per-deployment)
• IP-based tracking for security events

​

Layer 5: Audit & Monitoring

• All security events logged (security_events table)
• Failed login attempts tracked (login_attempts table)
• Credential access logged with IP/user-agent (deployment_secret_access_log table)
• Tool invocations logged for debugging and security analysis

​

How We Protect Your API Credentials

​

The Problem with Client-Side Storage

• ❌ Keys visible in browser DevTools
• ❌ Keys captured by session recording tools
• ❌ Keys leaked via XSS attacks
• ❌ Keys accessible to malicious browser extensions

​

Our Solution: Server-Side Only

1. Upload: When you provide API credentials, they’re sent directly to our edge function via HTTPS
2. Encryption: Immediately encrypted using AES-256-GCM with a server-side encryption key
3. Storage: Encrypted blob stored in database with RLS policies enforcing ownership
4. Usage: When your MCP server needs credentials, it requests them from a dedicated edge function
5. Retrieval: Edge function decrypts server-side, verifies ownership, logs access, and returns credentials only to authenticated backend services

• ✅ No keys in browser memory
• ✅ No keys in network traffic (except during initial upload, protected by TLS)
• ✅ No keys in frontend build artifacts
• ✅ Complete audit trail of who accessed what and when

​

Encryption Details

• Key size: 256 bits (industry standard for sensitive data)
• Mode: GCM provides both encryption and authentication
• Why GCM?: Detects tampering attempts, prevents replay attacks

• Encryption keys stored in Supabase secrets (never in code)
• Keys rotated independently from data (allows credential re-encryption)
• Each deployment’s credentials encrypted separately

​

Authentication & Access Control

​

User Authentication

• New signups must verify email before accessing dashboard
• Automatic sign-out after signup prevents “logged in but unverified” state
• Verification tokens expire after 24 hours
• Built-in rate limiting on resend verification (prevents spam)

• Managed by Supabase Auth (battle-tested authentication system)
• Passwords never stored in plaintext
• JWT tokens for session management (1-hour TTL)
• Refresh tokens for extended sessions

• Failed login attempts tracked by email and IP
• Progressive lockouts: 5 attempts = 15 min, 10 = 1 hour, 15+ = 24 hours
• Rate limit checking before authentication (prevents brute force)
• Lockout bypass requires waiting or admin intervention

​

OAuth 2.1 for Third-Party APIs

• Users grant permissions without sharing passwords
• Tokens can be revoked independently
• Scopes limit what the MCP server can access
• Industry standard for API authorization

• PKCE required (Proof Key for Code Exchange) - prevents authorization code interception
• State parameter - prevents CSRF attacks
• Token hashing - refresh tokens stored as SHA-256 hashes, not plaintext
• Token rotation - old refresh tokens invalidated on use
• Expiration tracking - access tokens (1 hour), refresh tokens (30 days), authorization codes (5 minutes)

• Authorization codes single-use only
• Redirect URI validation prevents token theft
• Client secrets never sent to frontend
• Token exchange requires client authentication

​

Row-Level Security (RLS)

-- Example: deployments table
CREATE POLICY "Users can view their own deployments"
ON deployments FOR SELECT
USING (auth.uid() = user_id);

-- Example: approved gallery items are viewable by everyone
CREATE POLICY "Anyone can view gallery template deployments"
ON deployments FOR SELECT
USING (is_gallery_template = true);

-- Example: admins can view all deployments for moderation
CREATE POLICY "Admins can view all deployments"
ON deployments FOR SELECT
USING (has_role(auth.uid(), 'admin'));

• SQL injection attacks cannot bypass ownership checks
• Compromised API keys don’t grant access to other users’ data
• Even with direct database access, users only see their own records

​

Rate Limiting & Abuse Prevention

​

User-Level Rate Limits

• Hourly request limits (default: 250 requests/hour)
• Monthly request limits (default: 1,500 requests/month)
• Deployment creation limits (default: 3 active deployments)
• Endpoint limits per deployment (default: 50 endpoints)

• At 80% of limit: Warning logged to security events
• At 100% of limit: Requests blocked with 429 error
• User notified with clear guidance on upgrading

​

OAuth-Specific Rate Limits

​

Gallery Deployment Rate Limits

• Per-user limits: 5 deployments/hour, 20 deployments/day (Free plan)
• Prevents automated scraping of gallery templates
• Ensures fair resource allocation

​

Audit Trails & Monitoring

​

What We Log

• Login attempts (success/failure)
• Token rotations
• Rate limit warnings/violations
• Suspicious activity detection
• Security dashboard access

• When credentials are retrieved
• Who requested them (user_id)
• From where (IP address, user agent)
• What secrets were accessed (jwt_token, api_key)
• Request correlation ID

• Which MCP tool was called
• API method and URL
• Response status and execution time
• Success/failure with error messages
• User ownership tracking

​

What This Means for You

​

Data Privacy

​

What We Store

• Email address (for authentication)
• Display name (optional)
• Security events (for audit trail)

• OpenAPI specifications (your API schemas)
• Encrypted credentials (your API keys/tokens)
• Deployment configurations (auth methods, customizations)
• Usage metrics (request counts, timestamps)

• Tool invocations (what tools were called)
• Security events (login attempts, rate limits)
• Deployment logs (generation status, errors)

​

What We DON’T Store

• ❌ API request/response payloads (we’re a router, not a logger)
• ❌ Plaintext credentials (always encrypted)
• ❌ Personally identifiable information from your APIs
• ❌ Conversation history between users and AI assistants

​

Data Retention

• Active deployments: Indefinitely (while your account is active)
• Logs: 90 days (automatic cleanup via scheduled jobs)
• OAuth tokens: Until expiration or revocation
• Security events: 90 days

​

Deployment Security

​

OpenAPI Spec Validation

• Maximum spec size: 5MB
• Maximum depth: 20 levels (prevents stack overflow)
• Circular reference detection
• Schema key count tracking (prevents database limits)
• URL validation and sanitization

• Small specs (<8,000 keys): Stored in database for fast access
• Large specs (≥8,000 keys): Stored in file storage to avoid database limits
• Supports enterprise APIs (e.g., Fortnox: 460 schemas, 233 endpoints)

​

MCP Server Deployment

• Cannot access other users’ deployments
• Cannot query other users’ credentials
• Cannot bypass rate limits

• JWT tokens generated per deployment
• API keys unique per deployment
• Secrets rotatable without redeployment

​

Incident Response

​

If You Suspect a Security Issue

1. Write in our Discord: https://discord.gg/tamXgrqxAF
2. Rotate your API credentials in the original API provider
3. Revoke OAuth tokens if using OAuth
4. Check your security events log for suspicious activity

• Publicly disclose the issue before we’ve had a chance to investigate
• Continue using compromised credentials

​

Our Commitment

• Response time: Within 24 hours for security reports
• Fix timeline: Critical vulnerabilities patched within 48 hours
• Disclosure: We’ll inform affected users promptly
• Transparency: Post-mortem published for significant incidents

​

Compliance & Standards

​

What We Follow

​

Future Certifications

• SOC 2 Type II (security, availability, confidentiality)
• ISO 27001 (information security management)
• GDPR compliance (data protection and privacy)

​

Technical Details for Security Auditors

​

Database Security

• Version: 15+ (latest stable)
• All tables protected by RLS policies
• Service role usage logged and audited
• Foreign keys enforce referential integrity
• Indexes on security-critical columns (user_id, deployment_id)

• Managed by Supabase (encrypted backups)
• Point-in-time recovery available
• Disaster recovery plan documented

​

Edge Function Security

• Sandboxed execution (no file system access by default)
• TypeScript for type safety
• Secure-by-default APIs

• Zod schemas for all request validation
• Structured error responses (TydliError type)
• CORS validation on all endpoints
• Rate limiting implemented at function level
• Service role access controlled and logged

​

Authentication Flow

1. User submits email + password
2. Supabase Auth creates user record
3. Verification email sent
4. User signs out immediately (prevents unverified access)
5. User verifies email via link
6. User logs in → JWT token issued
7. Dashboard access granted

Access token: 1 hour TTL
Refresh token: 30 days TTL
Session: Maintained via refresh token
Expiration: Automatic logout, re-authentication required

​

Credential Storage Flow

1. User provides credentials (HTTPS POST)
2. Edge function receives credentials
3. Validate user ownership of deployment
4. Generate encryption key (if not exists)
5. Encrypt using AES-256-GCM
6. Store encrypted blob in api_credentials table
7. Log encryption event to security_events
8. Return success (no plaintext in response)

1. MCP server requests credentials
2. Edge function validates authentication
3. Verify deployment ownership
4. Check rate limit (5 req/min)
5. Retrieve encrypted blob
6. Decrypt using server-side key
7. Log access to deployment_secret_access_log
8. Return plaintext to backend service only

​

FAQ

​

Q: Can Tydli.io employees see my API credentials?

​

Q: What happens if Tydli.io is compromised?

1. Attacker would need database access (protected by authentication)
2. AND the encryption keys (stored separately in Supabase secrets)
3. AND bypass RLS policies (enforced at database level)
4. AND evade audit logging (would be detected)

​

Q: How do you prevent AI from leaking sensitive data?

1. AI sends request to MCP server: “Get customer list”
2. MCP server translates to API call: GET /customers
3. MCP server retrieves credentials (server-side)
4. MCP server calls your API with credentials
5. MCP server returns sanitized results to AI
6. AI never sees credentials, only business data

​

Q: What if I lose access to my Tydli.io account?

1. Use account recovery (email-based)
2. If recovery fails, contact support with proof of ownership
3. As a last resort, rotate keys in your original API provider

​

Q: Are my OpenAPI specs visible to other users?

​

Q: How do gallery templates work securely?

1. A new deployment is created in YOUR account
2. YOU provide API credentials
3. Credentials are encrypted and stored separately
4. Original template remains public, your instance remains private

​

Q: Can I self-host Tydli.io for extra security?

​

Comparison with Alternatives

​

Building Your Own MCP Server

• ❌ You handle credential storage (easy to get wrong)
• ❌ You implement rate limiting (often forgotten)
• ❌ You maintain audit logs (complex to build)
• ❌ You secure the deployment (server hardening required)

• ✅ Battle-tested credential encryption
• ✅ Built-in rate limiting at multiple levels
• ✅ Comprehensive audit trails
• ✅ Managed infrastructure with security updates

​

Using API Keys in AI Assistant Configs

• ❌ Keys stored in plaintext configuration files
• ❌ Keys synced across devices (more exposure)
• ❌ No rate limiting (can exhaust API quotas)
• ❌ No audit trail (can’t track usage)

• ✅ Keys never stored client-side
• ✅ Centralized credential management
• ✅ Per-deployment rate limits
• ✅ Complete usage visibility

​

Conclusion

• 🔒 Your credentials are encrypted with military-grade encryption
• 🚫 Your credentials never touch client-side JavaScript
• 👤 Your data is isolated via Row-Level Security
• 📊 Every security event is logged and auditable
• 🛡️ Multiple layers of defense protect against attacks

• We document our security practices publicly
• We respond to security reports within 24 hours
• We publish post-mortems for significant incidents
• We maintain a public security roadmap