Your next customer interface is one you won’t build.

No. Lockkeeper runs inside your own cloud subscription. Nothing passes through infrastructure we operate. Tokens stay in a vault on your own cloud and requests stay inside your boundary. We deliver containers, a Helm chart, configuration and infrastructure code in the tooling you already use; you run them. The one place data does leave is the assistant itself. See the question on the assistant provider below.

The channel runs on your infrastructure in your region, with a data-processing picture you can defend. Each pilot includes a threat model, input for your DPIA and a runbook. Audit records go to immutable storage with a fixed retention period. Debug telemetry goes separately, through OpenTelemetry, to your own platform, so there are no gaps in the audit trail and no personal data in debug logs. The gateway logs without tool-result content. The evaluation suite checks for cross-tenant leakage before and after go-live. Data that reaches the assistant provider is a separate question, answered below.

Your team runs it, from day one. It is your API and your cloud, so monitoring, on-call and incident response stay with your platform team, and we build the channel to fit the way you already operate. Every pilot ends with a handover: standard technology, a test cycle, documentation, a runbook, and the evaluation harness as a regression test. There is no black box, and your licence on our background IP is perpetual. The retainer is for extending the channel, not for keeping it alive.

You own the deliverables: your capabilities, configuration, integration code and documentation. Ferox Systems keeps its background IP: the methodology, the architecture patterns and templates, the evaluation approach and the generic MCP container. You receive a perpetual, non-exclusive licence to all of it, so it does not expire and nothing depends on us staying. This split is written into every contract.

No. Your apps keep deciding. Lockkeeper maps scopes, IDs and personas onto the rights your APIs already enforce, so there is no second copy of your permissions to go stale. Where an API only accepts a service credential, we first look at making it accept the user’s own token. Where that is not possible, Lockkeeper enforces the rules from your system of record, and we limit that path to what is strictly needed.

Yes, and that is a natural place for a first pilot: the same approach, less risk. The goal is your customer channel; your own employees are the easy first step, with the same identity, the same rights and the same audit trail.

As little as possible, and nothing standing. We work in your repositories and your pipelines: changes arrive as pull requests, your GitOps tooling deploys them, and your team approves. For the build we need a non-production environment, test identities and the relationship data to model against. Production access stays with your team.

The gateway is one of the building blocks we use: token validation, rate limits per tenant, the kill switch. Its built-in endpoint-to-MCP conversion solves the easy part, and anyone can do that. We design the capabilities per customer instead of mirroring endpoints, because the hard parts are elsewhere: an assistant picking the right capability from natural language (which the evaluation suite checks), your users’ own identity carried through a third-party assistant, your apps’ existing rights respected on every call, confirmation on writes, and the compliance evidence.

Any client that speaks the Model Context Protocol over Streamable HTTP, which today includes Claude, ChatGPT, Copilot, Gemini and most agent frameworks. Lockkeeper auth registers each client and runs the OAuth flow it expects. Every pilot is validated against two different clients to prove the channel is client-agnostic.

Same account, one extra consent step. Users sign in with the identity provider they already use. Lockkeeper’s auth service runs the OAuth flow the assistant needs, federates to your provider and keeps the resulting tokens in a vault on your cloud. The assistant never holds a credential of its own, and nothing is passed through to your backend.

Whatever a capability returns ends up in the context of the assistant your customer uses. That sits with Anthropic, OpenAI, Microsoft or Google, outside your cloud and outside our control. Two things keep it in check. Capabilities are designed to return the minimum the task needs, not whole records. And your own data processing agreement with the assistant provider covers what leaves. We put this on the table with your DPO in week one, not after go-live.

Azure. That is where the reference architecture was built and where we have the deepest experience. Everything Lockkeeper adds is packaged as containers and a Helm chart and built on open standards: MCP, OIDC and OAuth 2.1, OpenTelemetry. Nothing you receive is tied to a service we host. If you run on another platform, ask, and we will tell you plainly what we have delivered there.

Lockkeeper is a consultancy with a reusable approach, run by Ferox Systems BV in Oostende, Belgium, the company behind Kubeforge and a Microsoft Cloud Solution Provider partner. Years of production platform engineering on Azure and Kubernetes is where the reference architecture comes from. You talk to the person who designs and builds your channel; your own team runs it afterwards.

A lockkeeper decides who passes, when, and under which conditions. The word is the international form of the Flemish sluiswachter, which ties the brand to its origin on the Belgian coast. A lock does not stop traffic. It lets it through in a controlled way, one chamber at a time, with someone accountable at the gate. That is what we build for your API.