Becoming an AI-first organization at Akka means more than giving employees access to a chat interface; it means connecting AI to the tools and data that drive our business, securely and responsibly. The Model Context Protocol (MCP) has emerged as the standard for doing exactly that, linking AI clients to external services. But wiring up each service individually, per user, per machine, introduces security gaps that put both employee and customer data at risk, and quickly becomes unmanageable to govern at scale.
The Akka MCP Gateway solves this: a single, centrally-managed proxy that sits between our employees' MCP clients and our business tools, handling authentication, authorization, and auditability in one place. Built on Akka, it is designed to be durable, stateful, and production-ready from day one.
The problem: MCP has no organizational governance or safety controls
The standard MCP authorization model is user-scoped. Every employee connects to every MCP server individually, with no shared policy or oversight. In practice this means:
- No central policy enforcement: security teams have no consistent control over what tools are accessible to whom, or what those tools are permitted to do.
- No audit trail: there is no unified log of which AI agent called which tool on whose behalf.
For individual developers, this is a mild inconvenience. For any organization wanting a unified, governable interface to AI tools (giving technical and non-technical employees alike a consistent, understood experience), it is a significant blocker.
The solution: central control without central friction
The gateway acts as a trusted intermediary that MCP clients (e.g. Claude Code, Cowork, IDE plugins) authenticate against once, via our organization's identity provider (Okta). From there, it handles everything else:
Single sign-on entry point. Employees log in once with their corporate Okta credentials. The gateway issues a session token that MCP clients use for all subsequent requests, and employees never gain more access than their existing Okta roles already permit.
Permission mirroring from Okta. The permissions and group memberships managed in Okta are mirrored in the gateway. This allows us to maintain a curated list of downstream MCP services (e.g. Zoho Desk, Salesforce, and others) and control exactly who has access to which of them. Employees only see the tools they are authorized for, based on the roles already defined in our identity provider.
Standards-compliant authorization. The gateway implements the MCP authorization specification out of the box. Any MCP-compatible client connects without custom configuration.
Authenticated proxy to upstream services. Behind the scenes, the gateway maintains connections to Zoho Desk, Salesforce, and other tools. It injects the correct credentials into each upstream request and refreshes them automatically when they expire.
Safe by default, flexible by design. All tools are read-only by default. Elevated permissions (e.g. write access, destructive operations) can be granted on demand, scoped to specific tools, and time-boxed so access expires automatically. This means employees cannot perform destructive actions until the organization is explicitly ready to permit them, protecting both internal data and customer records.
Durable interaction log. Every MCP tool call is recorded: tool name, parameters, response, user, timestamp. This gives security and compliance teams a complete, tamper-evident audit trail.
A single interface across the organization
The gateway pattern is useful anywhere an organization wants AI agents to interact with internal tools safely, with consistent governance across the team. A few examples:
Customer support teams can give AI assistants access to Zoho Desk or Salesforce CRM without exposing individual credentials or risking unauthorized data modification. Support agents complete a one-time connection and their AI client is immediately governed by the same access controls as everything else.
Developer platforms can expose internal tools (e.g. issue trackers, monitoring dashboards, deployment systems) as MCP servers, then use the gateway to ensure only authenticated, authorized employees can invoke them, with a complete call log for compliance.
The governance story is the same regardless of role. Engineers, support staff, and executives all operate through the same gateway with the same Okta-defined permissions, with no special configuration and no different rules for different teams. Everyone gets a consistent interface to AI tools; no one sees more than their role permits.
Why Akka is the natural infrastructure layer for agentic AI
The MCP Gateway has requirements that are a near-perfect match for Akka's distributed systems primitives. These aren't incidental: the gateway's core concerns map directly onto Akka's building blocks.
Event sourcing as the audit log. The tamper-evident audit trail is not bolted on as a separate logging concern. Every MCP tool call (i.e. request, response, connection attempt, write rejection) is persisted as an immutable event by McpInteractionEntity, an Akka Event Sourced Entity. The audit trail is structurally guaranteed by the storage model itself. Adding an escalation status later is just another event, not an update that overwrites history.
Views for queryable projections over the event log. The interaction (audit) event log is append-only, but operators need to query it: by user, by MCP server, paginated, with total counts. Akka Views consume the event stream and maintain live, indexed read models. The same events that form the compliance record also power the operational dashboard, with no separate ETL step.
Entities for stateful credential lifecycle. OAuth tokens are inherently stateful: they are issued, expire, refresh, and are revoked. Akka Key-Value Entities give each service connection (e.g. Salesforce, Zoho Desk, Google Drive, and others) its own durable, in-memory state with atomic updates. Token refresh happens inside the entity's command handler, with no race condition between an expiry check and a concurrent refresh. Sessions and pending OAuth flows are entities too, surviving process restarts without a separate cache or database layer.
MCP proxying via LangChain4j, coordinated by Akka. Each upstream service has a dedicated client class (e.g. SalesforceMcpClient) that uses LangChain4j's DefaultMcpClient with StreamableHttpMcpTransport to call the upstream MCP server over HTTP. Before each call, it fetches a valid OAuth token directly from the corresponding Akka entity via ComponentClient; token refresh, expiry, and revocation are all handled durably by the entity, not by ad-hoc in-process logic. Akka provides the reliable state backbone; LangChain4j handles the MCP wire protocol.
Agentic AI workloads share a common set of hard infrastructure requirements: durable session and credential state, tamper-evident audit logs, consistent policy enforcement, and reliable proxying to external tools. These are not AI problems; they are distributed systems problems. Because all of this state survives restarts and scales horizontally, the gateway is production-ready without bolting on a cache, a database, and a logging pipeline separately.
The pattern generalizes: any organization deploying AI agents at scale needs exactly this substrate (i.e. stateful, auditable, policy-enforced access to business tools). Akka provides it out of the box. The MCP Gateway is one instance of a broader truth: Akka is the natural infrastructure layer for agentic AI.
Built with Akka Specify
The gateway is also a proof point for how Akka systems are built. It was developed using Akka Specify, Akka's spec-driven development tooling, going from requirements to running, tested code through AI-assisted prompting, with no manual scaffolding. The infrastructure layer and the development workflow reinforce each other: Akka handles the hard distributed systems concerns at runtime, and Akka Specify removes the friction of building those systems in the first place.
Outlook: enterprise-managed authorization
The Akka MCP Gateway was built before a formal enterprise auth standard existed. In June 2026, the MCP community published exactly that: the Enterprise-Managed Authorization (EMA) extension.
EMA formalizes the pattern the gateway implements: our organization's identity provider becomes the authoritative decision-maker for MCP server access. Administrators define policy once; employees get the right tools automatically on first login, scoped to their groups and roles, with no per-service consent screens and nothing to configure individually.
The Akka MCP Gateway is a natural stepping stone to this world. Our next step is to evaluate EMA as the path toward zero-touch provisioning: employees log into Claude once with their corporate identity, and every tool our organization has approved is available immediately.
The full source is open on GitHub at github.com/akka/mcp-gateway.
Posts by this author
Share this article