Production Security and Operations

The module provides layered controls, but production safety depends on disciplined Odoo users, correct proxy configuration, narrow bundles, credential lifecycle management, and audit review.

Warning: Do not make an Odoo administrator the default AI identity An administrator can access far more Odoo data than most AI workflows require. Use dedicated internal users with normal company and app restrictions.

Production checklist

• Use a valid HTTPS certificate and one canonical public origin.
• Use OAuth or OAuth + Scoped API Keys.
• Use bundle enforcement and explicit exact-model allowlists.
• Start every new workflow read-only.
• Block sensitive fields and unnecessary export, chatter, write, and delete tools.
• Apply forced domains for company, business unit, warehouse, state, owner, or date boundaries where appropriate.
• Set conservative global and per-model record ceilings.
• Restrict browser origins to the clients actually used.
• Use per-key IP allowlists for stable automations.
• Keep audit logging enabled and review denials and mutations.
• Back up and test module upgrades on staging.

Network controls

Allowed Browser Origins protects browser-based Streamable HTTP access. API keys also support exact IP addresses and CIDR allow or deny rules. Deny rules take precedence. Forwarded client IP headers are trusted only through loopback or private reverse proxies.

Rate limits and cache

Global rate limiting is disabled by default because clients can make discovery bursts. Enable it after measuring real setup and usage. A key-specific limit overrides the global behavior for that key. Response caching is optional and applies only to governed read behavior.

Shared Redis

Enable Redis for multi-worker or multi-server deployments that need shared cache entries, sliding request limits, and failed-authentication protection. Install the redis Python package, use redis:// or rediss://, test the connection from Settings, and keep credentials out of logs and documentation.

Deliberate safety boundaries

• No arbitrary SQL supplied by clients.
• No arbitrary Python execution.
• No arbitrary JavaScript or HTML in dashboard specifications.
• No generic unrestricted Odoo method calls in the normal production tool surface.
• No exposure of Odoo security metadata, configuration internals, module management internals, or MCP credential records through generic model tools.

Upgrade routine

1. Back up the database and module directory.
2. Replace the module code and restart Odoo.
3. Upgrade niyu_mcp_server on staging.
4. Review the canonical public URL, auth mode, data-access mode, bundles, model governance, and keys.
5. Reconnect clients or refresh tool definitions.
6. Test identity, read, analytics, export, and each permitted mutation.
7. Review Connections, Audit Logs, and Async Jobs before production rollout.