You are handing us keys. Here is what holds them.

Your upstream credentials

An API token you paste into Omniio is encrypted with AES-256-GCM before it reaches the database. The key lives in the deployment’s environment, never in the database beside the data it opens, so a copy of the database on its own is a copy of ciphertext. Each record carries its own initialisation vector and authentication tag, which means a tampered row fails to open rather than opening into something else.

• Tokens are decrypted in memory, for the one call that needs them, and attached to that call’s request to the upstream server. Nothing writes a decrypted token back anywhere.
• OAuth grants to upstream servers are held per user and refreshed on demand. Your grant is never used to serve another account’s call.
• Disconnecting a server deletes its stored credential outright — it is a delete, not a flag.
• Credentials are not part of the audit trail. What is recorded is the arguments your agent sent and the result it got back; the token that authorised the call is added after that record is formed.

How a client gets in

Clients authorize against https://omniio.dev over OAuth 2.1 with PKCE required, and the token they receive is bound to https://mcp.omniio.dev as its audience. There is no long-lived API key to leak, and nothing to paste into a config file.

Registration is dynamic, so every client that connects — the desktop app, an editor, a script — registers itself and gets its own credential. That is what makes a connection revocable on its own: cutting off one client does not disturb the others and does not make you re-authorize anything.

• Every recorded tool call carries the client that made it, so “what did that machine do” is a filter rather than an investigation.
• Revoking deletes that client’s tokens and its stored consent. Tokens are checked against the database on every request and nothing about them is cached, so revocation takes effect on the client’s next call — not at the end of some window.
• Sessions in the dashboard are separate from client tokens. Signing out of the browser does not disconnect your agents, and disconnecting an agent does not sign you out.

See your connected clients →

What an agent is allowed to do

Aggregation without control would mean one authorization buying an agent everything you have ever connected. Every tool on an enabled server has a mode, and you set it.

• Allow is the default, and it is the absence of a rule rather than a rule — connecting a server does not become a configuration chore.
• Deny refuses the call before any upstream contact happens. The tool is not called, and nothing about the attempt reaches the server.
• Ask first holds the call while it waits for you. The agent waits about a minute before it is told to try again, and the request stays approvable for fifteen — so the usual case, where you notice after the agent has given up, still works: approve it and the retry goes straight through. Email and web push tell you one is waiting.

Omniio also watches the servers themselves. Upstream tools are fingerprinted, and if a server changes what a tool does or what it accepts after you have started using it, calls to that tool are held until you have seen the new definition and accepted it. A server that quietly rewrites a tool you already trusted does not get to inherit that trust.

What is recorded

Every run_tool invocation is written down: the server, the tool, the arguments sent, the result returned, whether it succeeded, how long the upstream took, and which client asked. It is a record you can read, filter and export, not telemetry we keep for ourselves.

• Arguments and results are capped at 64 KB each, with the cut marked in place — a tool that returns multi-megabyte documents cannot quietly turn your audit trail into a storage bill.
• Entries are pruned on a daily schedule once they pass your plan’s retention window: 7 days on Free, up to 1 year on Enterprise. Pruning deletes rows; it does not archive them somewhere else.
• Erasure of everything held about you is a request away rather than a self-serve button today: ask, and it is done within the month the GDPR allows — usually the same week.

Limits, and what fails closed

An agent in a loop is the ordinary failure mode of this industry, and it is expensive in three directions at once — your bill, our database, and the upstream server’s own rate limits. Two ceilings sit in front of it.

• A monthly allowance, counted per MCP call and reset at 00:00 UTC on the first of the month.
• A burst ceiling per minute, from 60 / min on Free upward. It sits far above steady use of the same plan, so it catches runaways rather than work. A refused call is refused before it reaches an upstream server and is not billed.

Elsewhere, the rule is that a missing secret stops the feature rather than opening it. The scheduled jobs that prune and report usage require a bearer token and refuse every request when that token is not configured. Stripe webhooks are verified against the raw request bytes and a bad signature is answered with nothing useful.

Transport and browser headers

Everything is served over HTTPS. mcp.omniio.dev serves the MCP endpoint and nothing else — any other path on that host is redirected to the site, so there is no dashboard surface on the hostname your agents talk to.

These headers are on every response. They are read from the same module that configures them, so this list cannot describe a deployment that does not send them:

• Strict-Transport-Security: max-age=63072000; includeSubDomains
  Two years of HTTPS-only, subdomains included, so the MCP host cannot be downgraded either.
• X-Content-Type-Options: nosniff
  A response is the type it says it is; nothing stored is re-interpreted as script.
• Referrer-Policy: strict-origin-when-cross-origin
  A link out of Omniio carries the origin and never a path like /app/activity.
• Content-Security-Policy: frame-ancestors 'none'
  Nothing here may be framed, which is what stops a page being wrapped to harvest a consent click.
• X-Frame-Options: DENY
  The same rule for clients older than the directive above.
• Cross-Origin-Opener-Policy: same-origin-allow-popups
  A window we open cannot reach back into ours; popups still work, so clients that open the consent screen in one keep working.
• Permissions-Policy: accelerometer=(), camera=(), geolocation=(), gyroscope=(), magnetometer=(), microphone=(), payment=(), usb=(), browsing-topics=()
  Omniio asks for none of these, so an injected script cannot ask on our behalf.

Who else touches it

Omniio runs on other people’s infrastructure and says so. The full list, with what each one holds and where, is in the privacy policy; in short, hosting is Vercel, the database is Neon, payments are Stripe, and account email goes through a mail relay.

• Card details never reach Omniio. Checkout is hosted by Stripe and we store its customer and subscription identifiers, not a card.
• Semantic search over the tool catalogue is optional and, when it is on, embeds the catalogue’s tool names and descriptions — public metadata from the servers in the library. Your call arguments and results are never sent to an embedding provider.
• Analytics tags load only after you accept them, and never on the signed-in dashboard.

Read the processor list in full →

What we don’t claim

The useful part of a page like this is the part that is not flattering. Omniio is operated by Marco Lorenzo Qureshi Grima, a sole trader established in Malta, trading as Omniio (a LimitBreakIT product). VAT Reg No 3297-8402, registered as exempt under article 11 of the Value Added Tax Act (Malta).

• No SOC 2 or ISO 27001 report exists today. We have not been audited, and we will not imply otherwise with a badge. If your procurement process needs one, say so when you talk to us — it changes what we can sell you, and pretending otherwise wastes your time and ours.
• Encryption at rest is not a claim about us. Sealing credentials protects them from a stolen database copy. The key is in the environment the service runs in, so the operator can decrypt what the service can decrypt. Anyone telling you otherwise about a hosted product is describing cryptography they have not implemented.
• Data is not pinned to the EU yet. Some processors handle data outside the EEA under standard contractual clauses. EU-only residency is planned, not shipped, and it would be listed here as a fact if it were.
• There is no bug bounty programme. Reports are read and answered by a person; they are not paid.
• We do not train on your data and do not sell it. Tool calls pass through and are returned to your agent unchanged. Your arguments and results are stored for your audit trail and used for nothing else.

Report an issue

If you have found something, tell us before you tell anyone else and we will fix it. Reports go straight to the operator and are acknowledged within two working days.