Enterprise MCP Gateway

Enterprise agents become maintainable when tools, identity, policy, and auditability meet at one explicit control boundary.

A governed integration layer that turns enterprise APIs into safe, versioned tools for production AI agents.

At a glance

• Status: Enterprise platform pattern
• Architecture focus: Agents
• Primary outcome: Governed enterprise actions
• Stack: TypeScript, OAuth 2.0, JSON Schema, MCP, Observability

The challenge

Give agents useful access to SAP, Salesforce, and internal services without weakening identity, permissions, or operational control.

The architecture decision

Treat every tool as a versioned contract. Propagate user identity, validate inputs at the boundary, and make every action auditable.

System architecture

Responsibility moves through explicit boundaries. Each layer has one primary job; policy, health, and trace signals span the system.

Open the standalone architecture and workflow diagrams.

Architecture layers

1. Enterprise systems — SAP, Salesforce, and approved APIs remain the systems of record.
2. Connector adapters — Normalize authentication, schemas, errors, retries, and rate limits.
3. MCP registry — Publish discoverable, versioned tool contracts with ownership metadata.
4. Policy & identity — Propagate OAuth context, enforce scopes, and gate sensitive actions.
5. Agent runtimes — Allow approved assistants to discover and call tools through one route.
6. Audit stream — Capture tool inputs, outcomes, latency, cost, identity, and policy decisions.

How the system works

1. Discover — The agent receives only the tools permitted for the current user, tenant, and task.
2. Validate — Inputs are checked against strict schemas before any enterprise system is called.
3. Authorize — Identity and scopes are preserved; high-impact writes can require an approval step.
4. Execute and trace — The adapter normalizes the response while the gateway records a complete action trace.

Architecture decisions and trade-offs

ADR-01: Registry over point integrations

A central registry gives tools stable names, owners, versions, and lifecycle rules.

Trade-off: It adds platform governance, but removes duplicated authentication and error handling from every agent.

ADR-02: User identity stays attached

The gateway acts with the user’s delegated context instead of a broad shared service identity.

Trade-off: Token propagation is harder to implement, but least privilege and auditability are far stronger.

ADR-03: Deterministic boundary

The model may propose an action, but code validates, authorizes, executes, and records it.

Trade-off: The agent has less unconstrained freedom, in exchange for predictable enterprise behavior.

Production qualities

• Security: Scoped OAuth, tenant isolation, schema validation, secret separation, and approval gates.
• Reliability: Timeouts, idempotency keys, bounded retries, normalized failures, and circuit breakers.
• Observability: Task, model, tool, identity, latency, token, policy, and outcome traces are correlated.
• Evolution: Schema versions and deprecation windows prevent tool changes from silently breaking agents.

Outcomes

• One governed route to enterprise capabilities
• Reusable contracts across multiple agent runtimes
• Clear ownership and incident boundaries
• Evidence for security review and production debugging

Technology stack

• TypeScript
• OAuth 2.0
• JSON Schema
• MCP
• Observability

Related writing

• Production agent systems need bounds, not bigger prompts
• Evaluating an enterprise AI assistant beyond answer accuracy
• Tool contracts need version numbers and deprecation windows, just like APIs