Security
Governance as architecture, not a prompt.
monopea wraps a default-deny control layer around the agent: outward actions become proposals that wait for your sign-off, secrets are never shown to the model, and every decision is logged. Stored in Switzerland. Processed in the EU.
The gate
What happens when the agent wants to act?
By default, nothing — until you say so. Mutation-capable tool calls are never dispatched inline. The agent drafts the exact call as a pending proposal, the run blocks until you approve or reject, and only an approved proposal is dispatched. Unknown tools fail closed to review.
Propose → approve → dispatch
The agent plans and drafts the exact tool call — name, arguments, target — as a proposal. You see precisely what would run before it runs. Approval dispatches it; rejection records why. The run status is blocked_on_user while it waits.
Default-deny, fail-closed
The policy engine doesn't need to recognise a tool to be safe about it: a tool it has never seen fails closed to review. There is no path where an unclassified action slips through because nobody wrote a rule for it.
Autonomy is grantable — auditably
Governance isn't a straitjacket. You can explicitly grant per-tool, per-persona policies so trusted actions run without a stop — and the grant itself is a logged, reviewable event, exactly like the actions it permits. Autonomy expands by decision, not by drift.
Secrets
Can the model read my API keys?
No — structurally, not by promise. The vault is write-only: PUT a secret and it can never be read back; the API returns name, description, and last four characters only. The agent references it by placeholder, and the plaintext exists only at dispatch.
Placeholders, not plaintext
The agent writes {{secret:HUBSPOT_KEY}} in tool arguments. The runtime substitutes the real value only at dispatch — after approval — and scrubs any echo of it from tool results before they re-enter the model's context. The model never sees the value, in either direction.
Envelope-encrypted at rest
Stored values are envelope-encrypted, with the encryption bound to your tenant via AAD — a ciphertext lifted out of one tenant's rows cannot be decrypted in another's context. Rotation is a new PUT; deletion is a DELETE; neither ever reveals the old value.
Residency
Where does my data actually live?
Your persistent data — conversations, memory, knowledge graph, documents, encrypted secrets — is stored in Zurich, Switzerland (Postgres, AWS eu-central-2). Processing runs on EU infrastructure, and on the Swiss model track inference stays in Switzerland on Infomaniak-hosted models.
Persistent data — Zurich, Switzerland
Conversations, memory, knowledge graph, documents, encrypted secrets — Postgres on AWS eu-central-2.
Agent runtime — Paris, EU
The reasoning loop, tool dispatch, and the proposal gate run on EU infrastructure (Fly.io).
Dashboard & API edge — Cloudflare's network
The web app and API routes are served from the edge; persistent state still lands in Zurich.
Inference (CH track) — Switzerland
On the Swiss model track, inference runs on Infomaniak-hosted open-weight models (Qwen3.5-397B, Mistral 24B, Nemotron) — it stays in Switzerland when you choose the CH track.
Storage vs processing — why we spell out the difference
"Sovereign" marketing usually blurs where data rests and where it is computed on. We don't. Everything durable rests in Zurich; the agent's reasoning loop runs in Paris; the edge is Cloudflare. That split is a fact of the architecture, so we state it as one — stored in Switzerland, processed in the EU — and let you choose the CH model track when inference itself must stay Swiss. A residency claim you can verify is worth more than one you have to take on faith.
Isolation
How are tenants kept apart?
Two independent layers. The application scopes every read and write to your tenant — and beneath it, Postgres row-level security enforces the same boundary again with tenant JWTs the runtime mints per request. A bug in one layer is caught by the other.
App-level scoping
Every query, memory recall, knowledge-graph walk, and job is scoped to the calling tenant at the application layer — conversations, embeddings, documents, and personas included.
Postgres RLS underneath
Row-level security policies in the database enforce the same tenant boundary a second time, using tenant JWTs minted by the runtime — so even a mis-scoped query returns nothing that isn't yours.
Per-customer sub-keys
Within a tenant, customer_live_ sub-keys carve a further private scope: a sub-user's conversations, memory, documents, and personas are invisible to other sub-users, and their usage is metered separately.
Audit
What record is left behind?
A complete one. Every proposal, every approval, every rejection, and every dispatch is logged — including the autonomy grants themselves. Audit-chain checkpoints are Ed25519-signed, so the record isn't just a log you trust; it's one you can verify.
Everything through the gate is logged
Who proposed what, with which arguments; who decided, and why; what was dispatched, and what came back. Policy grants and revocations land in the same ledger as the actions they govern.
Ed25519-signed checkpoints
The audit chain is periodically checkpointed with Ed25519 signatures. Tampering with the history breaks the chain — the integrity of the record is cryptographic, not organisational.
No-retention mode
Can I run a turn the agent must not remember?
Yes. An incognito turn runs the full reasoning loop — it still reads existing knowledge so it stays useful — but persists nothing durable: no conversation row, no messages, no memory, no embeddings, no summary, no trace. When the turn ends, it's gone.
Pass incognito: true on a chat turn — via the dashboard, the REST API, or the WebSocket. It's a local no-retention guarantee: the turn is still metered, but it leaves no durable writes behind. Use it for one-shots over material that shouldn't enter long-term memory.
Compliance posture
Is this compliant with the EU AI Act?
Article 14 requires human oversight as an external control, not a prompt instruction — and Monopea's proposal gate is exactly that control, built into the architecture. We say the architecture was built for this; we do not claim a certification we haven't earned.
Where we stand, plainly
Monopea is architected for compliance-grade controls — the gate, the vault, the isolation layers, the signed audit trail. Formal certifications (SOC 2, ISO 27001) have not yet been obtained. When they are, you'll read it here first; until then, the mechanisms above are the proof we offer.
What fails closed — and what doesn't
One honest distinction: the tool-policy gate is fail-closed (an unrecognised action stops and waits for you), while spend metering is fail-open by doctrine — a metering hiccup degrades billing accuracy, never your agent's availability. Safety controls and accounting controls fail in the direction each should.