A central “Brain” so we stop handing out the server keys to everyone

A central service — nicknamed the “Brain” — becomes the single front door to Odoo, Shopify and email. It holds the secrets server-side, translates every call into “token → identity → role”, logs who did what, and exposes reusable business capabilities. The goal fits in one sentence: let the team create products without ever touching the server.

Context — the problem

To create a product in Odoo through an agent, you used to need an SSH key on the server and the know-how to handle a code repository. The result: either Hugo did everything, or broad server access got handed out to several people — impossible to trace, hard to revoke, and a single mistake could hit production. The real need wasn't “more access”, it was “the right capability, for the right person, with a trail”.

What was done

A central service (the “Brain”) was put in place as a single front door:

• It holds the secrets server-side; no one else sees them.
• Every call carries a personal token → an identity → a role (read / prepare / write / publish). You grant exactly the level that's useful, no more.
• Every action is written to a durable log (“who requested what, when”).
• One capability = one mold: a module + a route + an access scope, exposed on two surfaces — inside the command-line assistant and on an access-protected internal web page.
• Guardrails carried over from the legacy tool: anti-duplicate reconciliation before any creation, and a created product is never published automatically (publishing is a separate, explicit step).

Result: the service is in production, 3 accesses distributed to the team with distinct roles, 2 surfaces of use, and the codebase merged onto the main branch so that two people can now add their own capabilities and deploy them themselves, without going back through Hugo.

What was hard / what we learned

Separating two questions we always conflate. “Who holds the secrets” (the service, full stop) and “who's allowed to call what” (the token + the role) are two distinct problems. Once separated, granting access becomes reversible and traceable instead of a permanent gift.

The boundary, not the catch-all. We wrote down in black and white what must live inside the Brain (anything shared, anything that writes to a system, anything that must be traced / permissioned) and what can stay outside (deterministic crons, personal prototypes, read-only analytics). Without that rule, a central service quickly becomes a bottleneck.

Silly traps are expensive. The service wouldn't start because of a badly set working directory (an import error), and two components didn't “talk” because a single concept carried two different field names. The lesson: freeze a stable data contract between components early, and test the real startup, not just the code.

Keep the human on sensitive gestures. The assistant doesn't perform production writes and doesn't grant itself rights — a human triggers those. It slowed things down at times, but that's exactly the guardrail we want.

Stack

A service in Python (standard library, no dependencies), token → role authentication, a log on an embedded database, an API listening locally behind a reverse proxy, deployed as a managed service (systemd). Two surfaces: a skill for the command-line assistant + an access-protected internal web page. Odoo and Shopify as target systems.

What this illustrates

When several people need to drive the same systems, the right instinct isn't to distribute access, it's to build a front door: it keeps the secrets, translates “token → identity → role”, logs everything, and exposes reusable capabilities from the same mold. You move from “opening up access” to “exposing capabilities” — and the team gains autonomy without anyone losing control.