AI Solutions Exchange
Get started
Trust Center

Everything your security, legal, and procurement teams need — in one place.

AI Solutions Exchange is built to be reviewed and approved. Documents, controls, data flows, and a live vendor risk assessment are all published here — no NDA required.

Procurement hubDocument libraryStart vendor risk assessment
Organization-governed access

Organizations decide what their members can deploy

AI Solutions Exchange does not present every marketplace listing as automatically available to every member of an enterprise organization. Administrators define an AI Solutions Policy Profile — the models, capabilities, data-handling requirements, deployment modes, risk levels, creators, and licensing conditions permitted inside the organization. Each solution's machine-readable manifest is evaluated against that profile. Only solutions that satisfy the policy — or receive the required internal approval — are purchasable and deployable by ordinary members through the IDE extension.

Descriptive tags help classification and discovery, but the enforceable gate is the comparison between structured manifest fields and the organization's policy rules — not tags alone.

What the organization controls

The policy profile is composed from structured dimensions. Admins can set each independently and version the profile over time.

Business fit

  • •Approved business-use categories
  • •Approved departments
  • •Approved solution categories
  • •Approved industries

AI providers & models

  • •Approved AI providers
  • •Approved AI models (with version constraints)
  • •Approved deployment modes (hosted / org-controlled / private)

Risk & readiness

  • •Maximum enterprise-risk level
  • •Required certification or readiness score
  • •Required human review
  • •Required internal approval workflow

Capability restrictions

  • •Internet access allowed / prohibited
  • •File reads allowed / prohibited
  • •File writes allowed / prohibited
  • •Code execution allowed / prohibited
  • •Shell access allowed / prohibited
  • •MCP servers allowed / prohibited
  • •External APIs allowed / prohibited
  • •Elevated privileges allowed / prohibited

Data & jurisdiction

  • •Sensitive-data compatibility
  • •Geographic restrictions
  • •Data-residency requirements

Commercial & sourcing

  • •Approved solution architects or vendor organizations
  • •Licensing terms accepted
  • •Price or spend limits

Five evaluation outcomes

Every solution manifest is evaluated against the active organization policy profile. The engine returns exactly one of the following outcomes; the IDE extension renders visibility and actions based on the outcome and the member's role.

Approved

Manifest satisfies every rule in the organization's policy profile. Solution is visible and purchasable to eligible members inside the IDE extension.

Approved with conditions

Manifest satisfies core rules but triggers configurable conditions (e.g. reviewer sign-off, spend cap, restricted permissions). Members see the solution with the condition surfaced before license or execution.

Review required

Manifest matches rules that require organizational approval before general availability. Ordinary members do not see the listing; designated reviewers or admins evaluate and either approve, block, or attach conditions.

Blocked

Manifest violates one or more policy rules. Solution is not purchasable and cannot be executed within the organization. The block reason is shown to admins.

Unknown

Required manifest information is missing or the solution has not been analyzed against the current policy version. Availability is withheld until the gap is resolved.

Administrators and authorized reviewers may receive broader visibility for governance purposes than ordinary members — for example, the ability to see Review-required and Blocked entries and act on them.

The IDE extension as a thin client

Planned

The published IDE extension is designed as a thin authenticated client on top of the shared AI Solutions Exchange backend. All business logic — manifest generation, policy evaluation, licensing, setup validation, protected execution — lives in the platform. Adding a new editor (Cursor, Windsurf, JetBrains) means shipping a thin adapter, not a second backend.

Interface model

  • •Native IDE sidebar and tool-window navigation for catalog, licenses, active sessions, organization, and updates
  • •Native command-palette actions (e.g. "AI Solutions Exchange: Find a Solution")
  • •Buyer-safe solution details view
  • •Setup interfaces using native inputs where practical; dedicated panels only where genuinely required
  • •Protected-session panel for licensed interaction
  • •Explicit preview / insert / export / apply actions — never automatic

The website remains the marketplace, creator, organization-administration, procurement, Trust Center, and account-management surface. The extension is the execution and workspace-integrated access surface. The full website is not embedded inside an IDE webview.

Intended flow (planned)

  1. 1Sign in. The user authenticates through the IDE extension. The backend resolves their identity, organization membership, and role.
  2. 2Request approved catalog. The extension calls the shared public API for the organization-scoped solution catalog.
  3. 3Manifest evaluated against policy. For each candidate solution, the policy engine compares the unified capability manifest against the organization's active policy profile and returns one of the five outcomes.
  4. 4Filtered catalog rendered. Ordinary members see only Approved and Approved-with-conditions solutions. Review-required and blocked entries are hidden from members and surfaced to reviewers or admins.
  5. 5Solution details. The extension shows buyer-safe fields: capability manifest, security labels, compatibility, license terms, required permissions, and any organization conditions. Protected implementation content is never sent.
  6. 6License or request access. The member either uses an existing organization license, requests internal access, or purchases a personal license, depending on organization settings and role.
  7. 7Complete setup. The member fills the buyer-safe setup wizard. Simple fields use native IDE inputs; complex conditional forms use a dedicated setup panel.
  8. 8Validate readiness. The backend validates setup completeness, license entitlement, policy state, solution version, and selected model.
  9. 9Start protected session. For supported solutions, a server-controlled protected session begins. Solution logic stays server-side. The extension receives generated outputs and permitted actions only.
  10. 10Apply results. Workspace reads, writes, code insertion, command execution, or external transfers require explicit user authorization and must satisfy the solution manifest and organization policy.

Current vs. planned status

The backend surfaces required to power an organization-governed IDE extension are largely in place; the extension itself and full session runtime are planned.

Backend readiness

  • Unified capability manifestImplemented
  • Organization accounts and membershipsImplemented
  • Organization policy recordsImplemented
  • Public extension-ready APIsImplemented
  • API-key architecture (SHA-256, revocable)Implemented
  • Setup schemas and submissionsImplemented
  • Protected-content storage with forced RLSImplemented
  • Buyer-safe protected delivery policyImplemented
  • Compatibility and enterprise-risk metadataImplemented
  • Policy evaluation across every deployment pathPartial

Extension functionality

  • Published VS Code extensionPlanned
  • IDE-native approved-solutions catalogPlanned
  • Protected interactive session panelPlanned
  • Organization access-request workflow inside the IDEPlanned
  • Workspace-aware permission requestsPlanned
  • Thin adapters for Cursor, Windsurf, and JetBrainsPlanned
  • Full session authorization and replay protectionPlanned

Planned extension functionality is not represented as currently operational. See the data flow page for architecture diagrams, including the org-governed catalog flow.