The MCP Security Challenge
When you expose your Odoo data to an AI agent, you're giving that agent access to sensitive business information. Customers, invoices, inventory, salaries, contracts โ potentially everything in your ERP.
The security question is simple but critical: How do you let AI help you without letting it access everything?
This guide covers the security architecture of KSRO Labs MCP Server and best practices for production deployments.
Permission Inheritance: The Foundation
KSRO Labs MCP Server uses Odoo's built-in access control lists (ACLs) as the foundation. Here's how it works:
Step 1: You create an API key in MCP Server settings and assign it to an Odoo user (e.g., "Sales Agent").
Step 2: That Odoo user is granted specific Odoo groups (e.g., "Sales / Sales User").
Step 3: When an AI agent uses that API key, it inherits all permission restrictions of that Odoo user โ automatically.
Result: The AI agent can only access what the assigned user can access. No privilege escalation possible.
This is powerful because it means you don't have to create a separate security model. You reuse your existing Odoo access controls.
Field-Level Access Control
Odoo's native ACLs work at the model level. But what if you need to be more restrictive?
Example: A sales agent AI should query sale.order records, but ONLY see order lines and totals โ not customer_email, invoice_address, or tax_id (PII).
KSRO Labs MCP Server supports per-key field allowlists. When you create an API key, you can specify which fields are accessible:
Without Field Control
API Key can access sale.order โ sees customer_id, customer_email, tax_id, amount_total, payment_terms, margin, all fields
With Field Control
API Key for sale.order is restricted to: order_date, amount_total, order_lines. Customer PII is hidden.
This is critical for GDPR and HIPAA compliance. You can give AI agents access to operational data without exposing personally identifiable information (PII).
IP Restrictions & Rate Limiting
Beyond access control, KSRO Labs implements operational security:
๐ IP Allowlist / Denylist
- Restrict each API key to specific IP addresses (CIDR notation)
- Example: Only Claude API servers (IP range) can use key #1
- Example: Block specific IPs from accessing sensitive keys
- Prevents unauthorized access if key is leaked
โฑ๏ธ Rate Limiting
- Global limits: Max requests/minute across all keys
- Per-key limits: Different rates for different integrations
- Example: Sales agent key = 60 req/min; Analytics key = 10 req/min
- Protects against abuse and DoS attacks
Audit Logging: Compliance & Debugging
Every API call via MCP Server is logged. You can search and audit:
- Which API key made the request
- What action was taken (search, create, update, delete)
- What data was accessed
- When it happened (timestamp)
- Success or failure status
- Response time (latency)
- IP address it came from
Compliance benefit: For GDPR audits, you can prove "who accessed customer data and when." For SOC2 compliance, you demonstrate "comprehensive logging and monitoring of API access."
HMAC-SHA256 Webhook Signing
When Odoo sends webhooks to external systems via MCP Server, each webhook is cryptographically signed using HMAC-SHA256.
This ensures that the webhook actually came from Odoo and wasn't forged by an attacker. The receiver (e.g., n8n workflow, custom app) can verify the signature using the shared secret.
X-KSRO-Signature: sha256=abc123def456...
(Receiver verifies signature using the shared API secret)
Security Best Practices Checklist
Create separate API keys per integration
Don't reuse keys. One for sales, one for accounting, one for analytics. Easy revocation if compromised.
Use field allowlists for sensitive models
If an AI only needs order total and date, restrict it. Hide customer emails, tax IDs, margin data.
Set IP allowlists for production keys
Restrict keys to known IP ranges (Claude API, your office, n8n server). Prevents unauthorized usage.
Configure rate limits per key
Different integrations have different needs. Sales queries might allow 100 req/min; reports might allow 10.
Review audit logs monthly
Check for unusual access patterns, failed requests, unexpected models being queried. Identify anomalies.
Rotate keys periodically
Set auto-expiration or manually rotate keys every 90 days. KSRO supports zero-downtime token rotation.
Document your API key permissions
Keep track of which API key can access what. Helps with compliance audits and troubleshooting.
Monitor for suspicious activity
Set up alerts for: keys hitting rate limits, failed auth attempts, unexpected models being accessed, off-hours activity.
Compliance Frameworks
KSRO Labs MCP Server features support compliance with major frameworks:
๐ GDPR
- Access logging (who accessed what)
- Data access restrictions (field-level)
- Audit trail (90-day retention)
- Permission enforcement (inheritance)
- Ability to prove data access
๐ SOC2
- Comprehensive audit logging
- Access controls (ACL enforcement)
- Rate limiting & DDoS protection
- IP allowlists (network controls)
- Monitoring & alerting readiness
๐ฅ HIPAA
- Field-level access control (hide PHI)
- Audit logs (compliance requirement)
- Encryption of data in transit (HTTPS)
- Permission enforcement
- Role-based access