Status: stable — grounded in the canonical platform overview and concept system (0.8.0 concept freeze).

Why Xtrape

The problem

Every useful internal tool eventually grows the same organs: a way to configure it, a way to authorize who may use it, a place where its logs go, and someone who remembers how to restart it. Multiply that by every tool a team runs and you get many small, inconsistent management planes — each with its own notion of identity, its own audit gaps, and its own way of being unsafe when an AI system starts calling it.

Xtrape starts from a single decision:

The Platform is a shared management and governance plane for tools that connect to it, instead of each tool building its own management plane.

What the shared plane provides

The Platform owns the broadly reusable mechanisms every governed tool needs:

• Registration and discovery — a running tool becomes a registered Service with declared Capabilities, not an unlisted process.
• Lifecycle governance — admission, configuration, health, and handoff validation live in one place.
• Controlled interaction — operator UI, AI-facing exposure, and chat channels are parallel interaction products that consume the same shared foundations; none of them owns its own copy of registry, policy, or audit state.
• Policy and authorization mediation — authorization decisions are made by the Platform, per invocation, not by each tool's homegrown middleware.
• Credential references — services reference credentials through governed indirection rather than embedding secrets.
• Audit and event infrastructure — all managed execution is attributable, and history is immutable.

The boundary is deliberate in both directions. The Platform must not absorb business-specific behavior: if a function requires domain knowledge, or is not broadly useful to a large population of unrelated tools, it belongs outside the Platform — in the Service that owns it.

The vision

Turn user ideas into deployable Widgets and governable, observable running Services, and make their runtime units easy to define, compose, operate, and evolve — across products, environments, and implementation stacks. The core concepts (Artifact, Widget, Service, Capability) are defined independently of any concrete language or framework.

Design principles

1. Controlled exposure. Services declare capabilities; the Platform exclusively decides exposure eligibility and access-path authorization. Absent an explicit rule, nothing is exposed.
2. Invocation-relative authorization. Authorize the actual originator, the complete access path, the target resource, and the versioned operation — for every invocation and every downstream hop.
3. Narrowing only. The exposure baseline defines maximum exposure and minimum controls; account and token policy may narrow or strengthen it, never widen it.
4. Access path does not imply actor identity. The channel a request arrives through does not establish whether the originator is human, AI, automation, or another Service — policy must not assume it does.
5. Fail-closed side effects. External side effects route through an enforcement path that fails closed; declarative metadata alone never authorizes an external call.
6. Authoring is not operating. Building a tool (Studio/Workbench, design-stage) is separated from running and governing it; neither the authoring surface nor the operator UI holds deployment authority.

Read next: Positioning for how Xtrape relates to MCP, agent frameworks, and gateways, and Concepts for the full object model.