Vector databases

Sign up for Zilliz Cloud and keep its API key out of agent context

Zilliz Cloud signup requires verified email plus name and company onboarding before the API-key screen is available.

Trusty Squire completes that recorded sequence and vaults the credential; cluster endpoints, project IDs, and collection configuration stay explicit application choices.

Ask your coding agentUse Trusty Squire to sign me up for Zilliz Cloud, save the API key, allow api.cloud.zilliz.com for server-side requests, and wire it into this app without exposing the raw key.
Registry status
Active
Recorded actions
15
Credential fields
1
Provider entry
cloud.zilliz.com

What this setup unlocks

A vaulted Zilliz Cloud API key for the managed vector-database operations available on the account.

  • Ingest embeddings into managed Milvus collections.
  • Run semantic or hybrid vector search from a backend.
  • Give an indexing service revocable Zilliz access.

What your agent does

These public steps preserve the active registry flow while omitting captured account identifiers, brittle DOM selectors, and literal form values.

  1. 01

    navigate

    Open Zilliz Cloud signup.

  2. 02

    fill

    Supply a generated work email and generated password; no captured password is retained publicly.

  3. 03

    click

    Submit signup.

  4. 04

    await email code

    Wait for and apply the email verification code.

  5. 05

    fill

    Supply generated name and company details.

  6. 06

    click

    Complete verification and skip optional onboarding.

  7. 07

    click

    Open API Keys.

  8. 08

    extract via regex

    Capture the opaque Zilliz credential into the vault.

Credential saved to the vault

  • ZILLIZ_API_KEY

    ZILLIZ_API_KEY is a opaque api_key validated at 10 to 64 characters.

Write-only by design. Treat ZILLIZ_API_KEY as backend-only. Ask Trusty Squire to mint a grant for Zilliz Cloud, store its base URL and token as SQUIRE_EGRESS_BASE_URL and SQUIRE_EGRESS_TOKEN in server-side configuration, and send provider requests through that base URL. The host-scoped, revocable grant token is still a bearer secret, but the raw provider credential stays vaulted and is injected only at the boundary.

Use it without revealing the provider key

In the Vault, first make api.cloud.zilliz.comthe credential's primary allowed host. Then ask your agent to call grant_app_access. It returns a host-scoped egress base URL and a revocable token; the backend uses those values to list the cloud providers available to Zilliz Cloud.

// One-time Vault policy: make api.cloud.zilliz.com
// the primary allowed host. Off-allowlist requests are refused.

// Then ask your agent to create a scoped grant:
grant_app_access({
  service: "zilliz",
  rate_limit_per_hour: 100
})

// Inject the returned fields from backend-only secret storage:
// SQUIRE_EGRESS_BASE_URL=<returned base_url>
// SQUIRE_EGRESS_TOKEN=<returned token>

const response = await fetch(
  `${process.env.SQUIRE_EGRESS_BASE_URL}/v2/clouds`,
  {
    headers: {
      Authorization: `Bearer ${process.env.SQUIRE_EGRESS_TOKEN}`,
      "Content-Type": "application/json",
    },
  },
);

if (!response.ok) throw new Error(`Zilliz Cloud returned ${response.status}`);
const clouds = await response.json();

Provider request checked against Zilliz Cloud REST API overview on 2026-07-15.

The egress token is still a secret. Keep SQUIRE_EGRESS_TOKEN in backend-only secret storage. Do not expose it in browser JavaScript, logs, or source control. grant_app_accessreturns this scoped token once through the MCP result, so it can enter agent context; it is not the provider key. Move it directly into your deployment's secret store, or useuse_credential when you need zero grant-token exposure. Grants are host-scoped, audited, and revocable without rotating the provider credential.

Frequently asked questions

How do I use the Zilliz Cloud API key without .env?
Ask your coding agent: “Use Trusty Squire to sign me up for Zilliz Cloud, save the API key, allow api.cloud.zilliz.com for server-side requests, and wire it into this app without exposing the raw key.” Trusty Squire captures the provider credential directly into its write-only vault instead of returning it for an .env file. ZILLIZ_API_KEY is a opaque api_key validated at 10 to 64 characters.
Can Trusty Squire automate Zilliz Cloud signup?
Yes, for the reviewed email flow. Open Zilliz Cloud signup. Wait for and apply the email verification code. A hard CAPTCHA, payment, phone requirement, or human-only decision still stops the run for you.
How does Zilliz Cloud MCP provisioning keep the API key private?
Trusty Squire is the MCP server between your coding agent and the vault. It stores the captured Zilliz Cloud credential as a write-only value, then returns a reference or scoped egress grant instead of the raw provider key. The backend grant can call only its configured provider host and remains revocable and auditable.
What can I do with the generated Zilliz Cloud credential?
Zilliz documents this bearer key for its control-plane API, including cloud, project, cluster, and other operations permitted by the account and key.
What should I verify before using Zilliz Cloud in production?
Cluster URI, project ID, database, collection, cloud, region, plan, and role are separate. Add those from Zilliz Cloud after account creation rather than treating them as part of the secret.