Skip to content
Status

AI Control Plane / Concepts

Concepts

The core concepts behind the AI Control Plane and how they fit together: identity, tools and MCP servers, security policy, observability, and organization settings.

The AI Control Plane sits between the people and agents in an organization and the tools they use. Tools are built from sources and served as MCP servers. Every call through them is attributed to an identity, checked against policy, and recorded. This page defines the concepts behind that flow and links to the page that covers each one in depth.

Flow of the AI Control Plane: Sources become Deployments, which produce Tool definitions, served by MCP servers and gateways, bundled into Plugins, and installed by People and agents, whose tool calls return to the MCP servers and gateways. Identity, Policy, and Observability each apply to every call through an MCP server.

Every action the platform authorizes or records is attributed to a principal: a person, an agent, or a workload. Attribution is what access rules, audit trails, cost reporting, and risk findings key on. See Identity for how identity is captured.

  • Identities are the people and agents the platform knows about, whether or not they hold an account. Membership comes from the organization’s identity provider through SSO and directory sync, and activity reported by AI tools is linked back to a person. See Identities.
  • Agents are first-class nonhuman principals with one human owner, their own policy, and credentials that can be revoked independently. When an agent acts, the agent is recorded as the actor, not its owner. See Agent identity.
  • MCP sessions are the OAuth connections the platform brokers between MCP clients and servers. Every tool call through a session carries both the person or agent behind it and the client that made it. Revoking a session cuts off access immediately. See MCP sessions and User sessions.
  • Remote identity providers are upstream OAuth and OIDC issuers the platform trusts to authenticate MCP clients and to obtain credentials for upstream services on a user’s behalf. See Remote identity providers.

Tools start as sources, become tool definitions through a deployment, and reach agents through MCP servers. See MCP Gateway.

  • Sources describe the functionality tools come from: OpenAPI documents, TypeScript functions, and existing MCP servers added from the catalog, by URL, or through a tunnel. See Sources.
  • Deployments are immutable snapshots of a project’s sources and the tools generated from them. Every source change produces a new deployment, and the latest successful one serves the project’s tools. See Deployments.
  • Tool definitions are the output of a deployment: one per API operation, function, or upstream MCP tool, holding what an LLM needs to call the tool and what the platform needs to run it. A tool’s name, description, annotations, and tags can be overridden without changing its source, which helps models choose and use the right tool. See Tools on a server and Tag-based tool filtering.
  • MCP servers expose a selected set of tools over streamable HTTP, each with its own authentication, visibility, and team access. A server is hosted, remote, or tunneled, depending on where its tools come from. See MCP servers.
  • Gateways put several MCP servers behind one address. An agent connects once and reaches every member through four tools that list, describe, and call the underlying tools on demand, so a large catalog stays out of the model’s context until it is needed. See Gateways.
  • Environments hold the secrets and configuration servers need to reach upstream systems, so credentials stay centralized instead of living in client configuration. See Environments.
  • Skills and plugins get tools to people. A skill packages instructions an agent loads. A plugin bundles MCP servers and skills, is assigned to roles, and is published to agent marketplaces such as Claude Code, Cursor, and Codex. See Skills and Plugins.

Policies decide what agents may do and flag or block what they should not. See Security and Policy.

  • Risk policies scan agent sessions for secrets, sensitive data, prompt injection, destructive tool use, and other risks. A policy combines detection rules, the content they examine, the action taken on a match, and the audience it applies to. See Guardrails and Detection rules.
  • Findings are the matches policies produce. They roll up into ranked signals on Watchdog and attach to the exact message in a session. See Watchdog and Risk events.
  • Shadow MCP and Shadow AI are the MCP servers and AI tools people use without going through the platform. Shadow MCP servers are discovered in agent traffic, and Shadow AI tools are reported by enrolled devices. Both can be reviewed and allowed or blocked. See Shadow MCP and Shadow AI.

Everything that flows through the platform is recorded and attributed. See Observability.

  • Agent sessions are captured agent conversations: a full transcript of messages and tool calls with cost and token attribution. They are where investigations start. See Agent sessions.
  • Tool logs are the raw record of every tool call the platform observes, across hosted, tunneled, and shadow MCP servers, skills, and local tools. See Tool logs.
  • Costs track AI spend from organization totals down to individual people and sessions. Budgets give each person a spending window that flags or blocks overspend. See Costs.
  • Data export sends logs, metrics, and traces to an external observability or SIEM destination over OpenTelemetry. See Data export.

An organization holds members, roles, billing, and the settings shared across its projects. Projects hold MCP servers, sources, policies, and the data they produce. Roles grant scopes, and scopes decide who can view or change each part of the platform. See Team, and Roles and Permissions.