Support Surfaces

The published OpenAPI specification  describes a subset of Keel’s public HTTP API. It does not include managed MCP server registration or tool calls. Use the route-specific public documentation for paths outside that projection; generated clients cover only the operations present in their input specification.

First-class runtime SDKs

Python and TypeScript are the only first-class runtime SDKs. They expose managed provider wrappers and Permit-first framework adapters. Each published adapter must be checked against the deployed API contract; source availability or an SDK release tag does not establish that a complete customer journey is supported.

pip install keel-sdk        # Python
npm install keel-sdk        # TypeScript

Framework adapter boundary

Permit-first LangChain, LlamaIndex, and Vercel AI adapters authorize the inner model invocation (generate.text). They use the application’s model client and credentials, so enforcement is cooperative. The Permit request carries no tool definitions, and it is not authority for tools the application runs after the model returns: those are outside Keel unless they go through a separately enrolled Keel-managed MCP connector. From keel-sdk 0.5.1 the adapters refuse provider-executed (built-in) tools before requesting a Permit, because Keel cannot authorize provider-side effects under a model-invocation label. Managed provider wrappers, proxies and /v1/execute keep model dispatch and credential custody in Keel, and they refuse requests that carry tool definitions. A model tool schema describes a possible tool call; it is not a managed MCP execution.

Adapters send the provider identity the framework reports. A known identifier maps to Keel’s canonical provider name; any other identifier is sent as reported (or unknown when absent), never relabeled as a different provider. Provider-keyed policy rules therefore see the real provider.

The published keel-sdk 0.5.0 framework adapters have a known compatibility defect: tool definitions select call.tools, which the current API rejects for model-provider Permit requests. Do not treat those adapters as a working tool-calling integration. The managed proxy recipes on Integration Coverage are distinct paths with their own stated limits.

Infrastructure surfaces

Terraform. The public provider manages API keys (keel_api_key) and organization membership (keel_organization_member) and reads permits (keel_permit). It does not manage policies, workspaces, policy attachments, or audit export configuration, and it is not a policy-as-code surface. See Terraform.

MCP governance is exposed through the /v1/mcp/* API surface. Keel governs managed MCP :call execution through permits and audit evidence for connector identities Keel has enrolled; a server a customer registers is held for review on every call, and its human-mapped tools stay review-only. Keel is not a generic MCP server, offers no MCP endpoint that agents connect to directly, and should not be submitted to MCP registries.

For official provider SDKs, model families, Vercel AI SDK, custom agents, and the current CLI boundary, see Integration Coverage.

Generated reference client

Go is published as an official generated/reference client for infrastructure teams. It is not a first-class runtime SDK — it is generated from the OpenAPI specification and intended for integrations where the canonical HTTP contract is sufficient.

go get github.com/keelapi/keel-go/pkg/keelclient

Release verification

Every keel-verifier release from v2.2.0 onward is signed through GitHub Actions OIDC with Sigstore and logged to Rekor. Download the wheel, Sigstore bundle, release manifest, manifest bundle, SBOM, and SBOM attestation bundle from the GitHub Release before verifying.

Verify the wheel:

cosign verify-blob \
  --certificate-identity-regexp 'https://github.com/keelapi/keel-verifier/\.github/workflows/release\.yml@refs/tags/v.*' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  --bundle keel_verifier-<VERSION>-py3-none-any.whl.sigstore \
  keel_verifier-<VERSION>-py3-none-any.whl

Verify the signed release manifest:

cosign verify-blob \
  --certificate-identity-regexp 'https://github.com/keelapi/keel-verifier/\.github/workflows/release\.yml@refs/tags/v.*' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  --bundle manifest.json.sigstore \
  manifest.json

Verify the CycloneDX SBOM attestation against the wheel:

cosign verify-blob-attestation \
  --certificate-identity-regexp 'https://github.com/keelapi/keel-verifier/\.github/workflows/release\.yml@refs/tags/v.*' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  --type cyclonedx \
  --bundle keel_verifier-<VERSION>-sbom.intoto.jsonl \
  keel_verifier-<VERSION>-py3-none-any.whl

Other languages

Clients for other languages can be generated for the operations in the published OpenAPI specification . They are not maintained as official Keel SDKs.

Promotion-from-archive rule

Any archived language (Swift, C#/.NET, PHP, Ruby, Rust) exits the archive only via:

1. A named, paying design-partner+ customer requiring the language as a contract condition, or
2. Three consecutive quarters of organic inbound requests citing the language as a procurement blocker.

Ecosystem catalysts alone (e.g., Apple Intelligence MCP support, Microsoft Agent Framework adoption, Laravel AI SDK growth) are signal, not trigger. Customer pull is the trigger.