The control layer for enterprise AI capabilities

01 Connected Systems

Connect any system, once

MCP One treats your enterprise tools as managed integrations, not ad-hoc connections. Administrators connect MCP or REST systems — Jira, GitHub, Salesforce, Stripe, AWS, and more — using a standard onboarding process. Once a system is connected, every AI capability built on top of it inherits the same governance layer automatically.

You connect the system. You choose what capabilities can reach it. AI cannot reach anything you haven’t explicitly brought in.

02 Capability Registry

One catalogue for every AI capability

Every AI capability your organisation creates or enables — connectors, skills, MCP-served actions, internal tools — is recorded in a single registry. Each entry carries an owner, a business purpose, the systems it touches, a risk classification, and its current approval status.

When the security team asks what AI capabilities exist and what data they can reach, this is where you answer the question. The registry is the source of truth, not a spreadsheet, not a Slack thread.

03 Approval Workflow

Approved before it runs

No capability is broadly available until it has passed through a review. Capability builders submit; designated reviewers assess purpose, ownership, connected systems, and risk; and they approve or reject with a recorded decision attached. The approval, the reviewer, and the date are part of the permanent record.

If your organisation needs a second review for high-risk actions or regulated data, you can require it. The default is structured rather than ad hoc — which means the conversation about risk happens before deployment, not after an incident.

04 Access Policy

Control who can invoke what

MCP One’s rule-based policy engine lets you define precisely which users or teams may invoke which capabilities — based on role, department, geography, data sensitivity, or the connected system involved. Each rule can allow access outright, deny it, or require a manual approval before the invocation proceeds.

Access governance at the action level means something different from access governance at the system level. A user might have a Salesforce account; that does not mean every AI capability should be able to write a contract on their behalf.

05 Vendor Library

Pre-built integrations, ready to govern

The Vendor Library is a curated collection of pre-built integration templates for the systems your teams use most — Jira, GitHub, Salesforce, and others. Administrators enable a template, attach credentials, and a baseline set of governed capabilities is ready to configure and put through the approval workflow.

You are not starting from scratch every time a team asks for a new AI integration. You are starting from a vetted baseline and making organisation-specific decisions on top of it.

06 Execution Brokering & Audit Log

In the path, not watching from outside

For brokered capabilities, MCP One sits directly in the execution path — not as an observer, not as a log collector, but as the control point the request passes through. When an AI agent invokes a capability, MCP One checks the approval state, enforces the applicable policy rules, allows or denies the invocation, and creates an execution event before the action runs.

The audit log is a structural byproduct of being in the control path. Every invocation is recorded with the capability, the caller, the result, and the policy decision. No separate monitoring tool required.

Regulatory note: Brokered execution evidence maps to the logging and record-keeping obligations that the EU AI Act (Art. 12, Art. 29) and GDPR (Art. 30, Art. 5(2)) place on AI deployers. The audit record is created structurally — it exists because MCP One was in the control path, not reconstructed after the fact.

07 Employee Catalogue

Approved capabilities, easy to find

Approved capabilities are published to an employee-facing catalogue with plain-language names, descriptions, intended users, owners, and connected systems listed clearly. Employees can find what AI capabilities are available and sanctioned for their role without needing to understand the integration architecture that sits beneath.

When the approved alternative is easy to find, employees have less reason to reach for unmanaged tools. The catalogue is also the place where adoption is measurable — you can see which capabilities are being used and which are not.

08 Credentials Management

Credential hygiene at scale

Connected systems need credentials to function. MCP One manages both shared service-account credentials for system-wide capabilities and per-user API keys for capabilities that require individual user identity. Credentials are stored centrally against the relevant connected system, not scattered across capability configurations.

When access needs to be revoked — for a departing employee, a changed policy, or a security event — the revocation happens in one place, not by tracking down every capability that stored a secret independently.