Skip to content
Lockkeeper

Reference architecture

Built from components you already run.

Cloud-neutral by design, built on Azure first. Every box is a role your platform team already operates, and your existing APIs keep deciding who may see what. Switch the view to see what it typically maps to on Azure.

An assistant calls through your public edge and API gateway into the Lockkeeper MCP server. It takes the user’s token from the auth service, calls your existing APIs with the user’s own rights, and records who asked, on whose behalf, what was called and what was decided.

Components

Every box, what it does, and what it is on Azure.

Public edge

  • The only public endpoint
  • WAF and TLS termination
On Azure

Front Door or Application Gateway, with WAF

API gateway

  • JWT validation on issuer and audience
  • Rate limits and a kill switch per tenant
  • Correlation IDs; logging without response content
  • Fronts the custom MCP server. Built-in REST-to-MCP conversion is not used, because capabilities are designed per customer
On Azure

API Management

Lockkeeper MCP server

  • Task-shaped capabilities over Streamable HTTP, stateless where possible
  • Write actions only through explicit user confirmation (MCP elicitation) and idempotency keys
  • Workload identity and a secret store; no secrets in configuration
On Azure

AKS or Container Apps, workload identity, Key Vault

Lockkeeper auth: broker and token vault

  • Runs the OAuth flow the assistant expects and federates to your identity provider; the assistant never sees your backend
  • Tokens encrypted at rest with the key in your own key vault; private endpoint only
  • Refresh tokens never leave the auth service; short-lived access tokens towards your APIs
  • Revocation per user and per tenant
On Azure

Container on AKS or Container Apps; keys in Key Vault; Azure Database for PostgreSQL on a private endpoint

Your identity provider

  • The one your users already sign in with, never a new one
  • OAuth 2.1, authorization code with PKCE
  • Federated to by Lockkeeper auth; your identity model stays as it is
On Azure

Entra ID for workforce users; Entra External ID or your existing CIAM for customers

Authorization: your apps decide

  • Your APIs enforce their existing rights. Lockkeeper maps scopes, IDs and personas onto them; there is no second copy of your permissions
  • 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 the system of record, and we limit that path to what is strictly needed
On Azure

Your APIs as they are. For the exception only: OpenFGA on Azure Database for PostgreSQL

Audit and telemetry

  • Audit records to immutable storage with a fixed retention period: who asked, on whose behalf, what was called, what was decided
  • Debug telemetry through OpenTelemetry to your observability platform
  • Kept apart: no gaps in the audit trail, no personal data in debug logs
On Azure

Storage with an immutability policy; OpenTelemetry to Log Analytics or Datadog

Your existing APIs

  • Unchanged, behind your internal gateway
  • Called with the user’s own short-lived token
  • The assistant’s token is never passed through
On Azure

Wherever they run today

Three properties of every deployment

  • Private by default

    Only the edge is public. The MCP server, the auth service and the audit store sit on private endpoints. Your existing APIs stay untouched behind their internal gateway.

  • Delivered as code

    Containers and a Helm chart through GitOps, with infrastructure as code in whatever you already use: Bicep, Terraform or Crossplane. Changes arrive as pull requests; your pipeline deploys them.

  • Evaluated, then regression-tested

    Realistic questions per assistant check that the right capability is chosen, that the assistant asks when something is ambiguous, stays out when it is not needed, and never returns data across tenants. The same suite runs after every change.

Week one

Five decisions we settle in week one of every engagement.

The questions anyone who has tried this will ask first. We bring the options; you pick.

Identity provider
The one your users already sign in with: your customer identity provider, or your workforce directory for internal users. Never a new one.
Assistant clients and consent
The MCP authorization spec expects assistants to register dynamically; most enterprise identity providers do not support that. Lockkeeper auth handles registration and the OAuth flow and federates to your provider. In week one we settle which assistant clients to allow and what your users see on the consent screen.
Token strategy, per API
The user’s own short-lived token wherever your API accepts one. Where an API only accepts a service credential, we first look at making it accept the user’s own token.
The exception path
Where an API only accepts a service credential and cannot be made to accept the user’s own token, Lockkeeper enforces the rules from your system of record, kept current by a sync, and we limit that path to what is strictly needed. A stale relationship is a data leak, so this stays the exception.
Data reaching the assistant provider
What a capability returns ends up in the context of the assistant your customer uses, outside your cloud and ours. Data minimization in capability design is the main control, together with your own data processing agreement with the assistant provider. We put this on the table with your DPO in week one.

Next step

Want this in your subscription?

A 30-minute whiteboard session with the person who designs and builds it. Bring your API owner and your security lead.

Book a conversationSee the offer