Giving power to agents without handing the keys to the LLM: inside AIsuru's MCP Gateway

A conversational agent that responds is useful. An agent that acts — sends emails, writes to a database, schedules jobs, queries other agents — is a different category of product. But the moment an AI can take real actions on real systems, the question is no longer «does it work?». The question is: who is acting, with which credentials, and who allows it?

This is the question that gave rise to AIsuru's MCP Gateway: the control plane that sits between AIsuru agents and the outside world, and that does one thing that looks simple but is decisive — it gives agents power without ever putting credentials in the hands of the language model.

In this article we open the hood: first the security model, then the three MCPs we built inside the gateway ,MCP AIsuru, MCP Persistence and MCP Scheduler.

The principle: credentials never pass through the LLM

This is architectural rule number one, and everything else follows from it.

When an AIsuru agent needs to use an authenticated tool (read an Outlook inbox, write to a database, call Microsoft Graph) it never sees the token. The gateway resolves the session's identity, retrieves the correct credential from its own encrypted store, and injects it at runtime into the channel toward the destination system. The model orchestrates what to do; the gateway decides with which keys. The keys remain invisible to the agent, to the prompts, and to the conversational logs.

On this principle we built a defense in depth, layer by layer:

Encryption at rest

Every sensitive secret — access token, refresh token, client secret, MCP server parameters, is encrypted in the database with Lockbox (AES-256-GCM) and a master key that doesn't live in the code. A database dump doesn't expose credentials in the clear.

Short-lived session tokens

Internal communication between the gateway and MCP sub-processes (e.g. the Outlook connector in DCR mode) is protected by a signed JWT (HS256) with a 15-minute expiry, enough for a single tool call. No long-lived tokens circulating between components.

IP allow-list on trusted paths

The endpoints that execute actions (/execute, tool discovery, persistence) can be locked behind an IP address allow-list that can be toggled on the fly: only authorized sources reach the execution plane, others get a neutral 403.

Isolation by identity

Every operation is tied to a principal derived from the AIsuru session. One user never sees or touches another user's data or tasks. And when an identity can't be verified (for example an anonymous session claiming to act on behalf of an email address) the gateway blocks, it doesn't guess.

Audit and kill switches

Every use of a credential at runtime is tracked in structured logs. And where needed, there are global kill switches and automatic circuit breakers that pause anomalous behavior without needing a deploy.

There's also a detail we particularly like, halfway between security and robustness: when an agent makes a mistaken call, the gateway doesn't respond with a cryptic technical error but with a semantic, actionable message ("this tool doesn't exist, maybe you meant X"). The model understands and corrects itself, instead of showing the user a "technical problem". It's security and reliability, because a predictable system is a system that's harder to break.

All of this runs on European infrastructure, consistent with AIsuru's positioning on AI Act compliance and data sovereignty.

On this foundation we built three internal MCPs. They aren't connectors to third-party services: they are native capabilities of the gateway, designed for agents that need to remember, collaborate, and act over time.

MCP AIsuru: agents talking to each other

The first internal MCP turns every agent into a conversation partner for other agents. With MCP AIsuru, an AIsuru agent can open a session toward another agent, ask it a question, search its knowledge, and use its answer as part of its own reasoning.

It's the foundation of multi-agent systems: a "concierge" agent that consults the legal specialist, the technical one and the sales one, and composes a single answer. Everything stays inside the platform, with the same session identity and the same security model as the rest of the gateway.

The interesting part is how it does it. Fast answers come back right away, in the same turn. Slow ones (a complex search, an elaborate generation) don't block: the heavy work is queued and the agent picks up the result in a later turn. This asynchronous, turn-based model prevents a long call from saturating resources, and makes orchestration between agents scalable rather than fragile. We brought this logic inside the gateway, replacing an external microservice: fewer surfaces, more control.

MCP Persistence: structured memory, isolated per agent

LLMs are stateless: they forget everything between one session and the next. MCP Persistence gives every agent a structured, lasting memory manageable entirely in natural language.

"Manage a customer directory for me with name, company, industry, last contact and notes." The agent understands the structure, creates it on its own, and from that moment manages it: inserts, searches, updates, deletes. No spreadsheet, no database to configure, no app to develop.

Behind the simplicity there's a rigorous isolation architecture, and this is where security takes center stage again. Every agent has its own dedicated MongoDB database, with its own technical user whose permissions are limited exclusively to that database. One agent's data is physically separated from every other's: there's no shared collection with a "tenant" field where a query error could leak someone else's data. There's an actual database boundary, with minimum-scope credentials.

And then a series of measures designed so that an AI can administer a database without hurting itself:

• Auto-indexing of new collections and an index advisor that suggests what to create before going to production, with a cap on the number of indexes to prevent the model from creating too many.
• Configurable retention (TTL) allowed only on recognized timestamp fields, never on arbitrary fields: automatic deletion is a powerful tool and needs to be fenced in.
• Anti-hallucination Data View. To show data in a table, the agent doesn't reformat numbers "from memory", it generates an HTML view served directly by the database and embeds it. The data you see is the data that's there, not a probabilistic paraphrase of it.

MCP Scheduler: agents that work even when you're not there

The third MCP is the one that closes the loop between "responding" and "acting over time". With MCP Scheduler a user, simply by talking to the agent, can say: "every morning at 7 analyze the CRM data and send me a summary" or "remind me to call the supplier in ten minutes". The gateway creates an autonomous task that runs in the background and that, at the set time, reopens a session with the agent and performs the work on its own, orchestrating its own connected MCPs.

It also supports multi-phase tasks: the agent performs a first step (produce a report), then subsequent steps in the same session, keeping context ("now send it by email", "now log it in the CRM"). A small autonomous workflow, described in a sentence.

Having an AI act without a human in front of the screen is exactly the scenario where security is non-negotiable. That's why the Scheduler is the most locked-down component of the gateway:

• No "blind" delegation: During execution, the task's authorization toward authenticated systems is a very short-lived mapping (with a hard cap), tied to the single credential the owner had at the moment of creation, revoked as soon as the task finishes. There's no impersonation: identity doesn't change, only the specific permission does, and every use is tracked.
• No ghost tasks: A task is persistent, it can run for months: creating one requires a verifiable AIsuru identity. Anonymous sessions are rejected, so every task remains attributable and revocable by its owner.
• Double isolation: A user sees and manages only their own tasks, and only those created on the agent they're talking to.
• Operational safety: A global kill switch stops all tasks instantly without a deploy; a circuit breaker automatically pauses a task after a series of consecutive failures; a dry run mode allows testing a task without executing irreversible actions. And jobs are never blindly retried: a task isn't idempotent (a repeated retry could mean sending the same email twice) so transient errors are absorbed by the next cycle, not duplicated.

Not one more connector: a control plane

The difference between an assistant that chats and an agent that works comes down to this: the ability to act safely. You can connect an LLM to a database in an afternoon. Building the layer that decides who can do what, with which keys, for how long, and under what audit ,that's the work.

AIsuru's MCP Gateway is that layer. And the three MCPs that run on top of it( AIsuru for collaboration between agents, Persistence for isolated memory, Scheduler for autonomy over time) aren't third-party integrations: they are native capabilities, designed from the start with security as a constraint, not an afterthought.

Because the agents of the future won't just respond. They will act. And the point isn't just to give them the power, it's to never have to hand them the keys.