Enterprise Agent Platform Integration

When enterprise or platform customers hand CloudBase capabilities to their employees or downstream users, three problems come up every time:

1. High authorization barrier: end users have no Tencent Cloud account, so they cannot authorize through a QR code or the developer console.
2. Key management risk: asking users to copy and paste a plaintext API Key invites leaks — it ends up in a repository or in chat history.
3. Uncontrolled agent behavior: resources generated by the model drift from the corporate baseline (for example, a cloud function is created without a VPC configuration and cannot reach the internal database).

The fix is an integration standard. This guide covers one built on two ideas: delivering credentials silently and constraining what the agent may do.

Three integration paths

Platform customers do not need to change anything underneath. Combining three mechanisms covers most internal scenarios and security requirements:

1. Custom agent expert: package the auth helper, the common skills, and the dedicated prompt into one expert. Employees load it once and start working.
2. System Prompt / Skill constraints: inject the corporate baseline (VPC configuration, resource naming rules) before the model calls any tool, so whatever it creates is compliant by construction.
3. Wrap or proxy the CloudBase MCP: proxy the core MCP tools so databases, cloud functions, and storage are reachable from your own platform. The gateway handles authentication, and it is also where you disable specific tools or audit the inputs and outputs of every call. Hands-on guide: Wrap a dedicated CloudBase MCP.

Integrate with an AI assistant

Paste this prompt into your AI coding assistant (Cursor, Windsurf, Copilot, or the agent platform you run in-house) and let it walk you through the setup:

AI integration prompt:

I want to connect this project to CloudBase enterprise agent platform capabilities.

Start by reading these references:

1. https://docs.cloudbase.net/skill.md
2. https://docs.cloudbase.net/en/solutions/cloudbase-platform-edition/enterprise-integration

Then ask me about our current system architecture, authentication model, and compliance requirements. Discuss the options with me — a custom expert, a modified system prompt or skill, or wrapping the MCP tools — and agree on an approach before helping me implement it step by step.

Who owns what

Responsibilities split cleanly between the platform and CloudBase:

Dimension	What CloudBase provides	What the enterprise / platform owns
Environment and compute	Tenant-isolated infrastructure (database, cloud functions, static hosting, storage); lifecycle APIs for high-concurrency environments	The mapping between employee or team accounts and environment IDs (envId) — who gets which environment
Identity and authentication	Environment API Key validation; issuing and verifying temporary credentials (STS)	Unified sign-in (WeCom OAuth, corporate SSO); distributing or withholding keys from end users
Tools and safety	The generic MCP implementation; row-level security (RLS) and security rules underneath the database	Intercepting and approving sensitive or destructive operations (dropping a table, wiping an environment); audit logs of tool calls
Agent control	Loading custom skills, system prompts, and model priority	Writing company-specific experts, governing shared skill packages, enforcing a global system prompt

1. Two-layer gateway and silent credential delivery

"Users without a cloud account" and "no plaintext keys" are solved the same way: put a two-layer gateway between the client agent and CloudBase so identity can be swapped without the user noticing.

1.1 Decoupling employee identity from environment credentials

Employees sign in to the internal workspace with an identity they already have. The gateway intercepts the request and maps that employee ID to an envId and apiKey:

• No plaintext keys: the long-lived API Key and envId stay with the platform and never reach the user, so they cannot leak through chat history or a client config file.
• No visible swap: the client uses a device flow or an embedded service. After the user clicks "authorize", the helper receives envId and apiKey and writes them straight into the local credential file.

1.2 Local credential exchange (STS)

A local tool (MCP server, CloudBase CLI) does not use the apiKey for day-to-day calls. It calls exchangeApiKeyForCredential to trade the key for a credential that lives 30 minutes:

curl -X POST "https://<envId>.ap-shanghai.tcb-api.tencentcloudapi.com/capi/credential" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer <apiKey>" \
  -d '{"env": "<envId>"}'

The temporary credential (TmpSecretId, TmpSecretKey, Token) is written to ~/.config/.cloudbase/auth.json in this shape. It is used until it expires, then exchanged again:

{
  "credential": {
    "tmpSecretId": "AKID...",
    "tmpSecretKey": "...",
    "tmpToken": "...",
    "tmpExpired": 1787036755000,
    "envId": "env-xxx",
    "authSource": "api_key",
    "apiKey": "ak-xxx"
  }
}

2. Worked example: a company-specific expert

To show how a custom expert plus Prompt / Skill closes the loop, here is a "full-stack mini program expert" built into a company's own client.

2.1 Expert design and the helper

The platform packages an auth helper (a self-contained helper.js) into the expert bundle.

enterprise-webdev-expert/
├── skills/
│   └── auth-bootstrap/
│       ├── helper.js          # Local callback helper
│       └── SKILL.md           # Skill declaration
└── manifest.json              # Expert description and prompt config

When an employee tells the expert "connect to CloudBase":

1. Start a local service: helper.js opens a one-shot HTTP server on a random local port (for example 127.0.0.1:4001).
2. Send the user to authorize: the helper opens the browser at the platform's authorization endpoint, https://auth.enterprise.com/login?cliAuth=1&_redirect_uri=...&port=4001.
3. Redirect back: after the employee signs in and picks an environment, the page redirects to http://127.0.0.1:4001/?authSource=api_key&envId=env-xxx&apiKey=ak-xxx.
4. Exchange and write: the helper receives the parameters, exchanges them for an STS credential, and writes ~/.config/.cloudbase/auth.json.

One click in the browser, and the key is delivered. Nobody copies a plaintext credential.

2.2 Constraining behavior with Prompt and Skill

When the model calls createFunction, it will not add the internal VPC on its own — general knowledge does not include your network. The function then cannot reach the internal database.

The platform sets a hard constraint in manifest.json or in a custom skill, using the System Prompt:

Example system prompt:

# CloudBase compliance injection (mandatory):
You are the [enterprise full-stack mini program expert], running inside the corporate network.
Whenever you create or update a cloud function on the user's behalf (for example createFunction),
you must inject the unified VPC configuration.

Fill these parameters silently. Do not ask the user for the IDs, and never omit them:
- vpcId: "vpc-5a6b7c8d"
- subnetId: "subnet-1a2b3c4d"

Example call shape:
{
  "name": "createFunction",
  "arguments": {
    "name": "my-internal-api",
    "vpcId": "vpc-5a6b7c8d",
    "subnetId": "subnet-1a2b3c4d",
    "code": "..."
  }
}

With that constraint in place, a plan without network parameters gets corrected before it runs, so everything the agent creates meets the corporate network baseline.

3. One application, one environment

How you lay out environments and directories decides both development speed and data safety. Follow physical isolation: one application, one environment.

✅ Correct: one app = one project directory = one workspace
workspace/
├── app-student-portal/        ➜ env-student-prd
│   └── .cloudbase/
└── app-teacher-ledger/        ➜ env-teacher-prd
    └── .cloudbase/

❌ Wrong: several apps in one directory
workspace/
└── school-systems/
    ├── student-portal/        ❌ shares the directory
    └── teacher-ledger/        ❌ shares the environment, indistinguishable

3.1 Why isolation has to be physical

When an agent starts, the tooling passes it the current workspace path. It cannot descend into other folders or tell them apart on its own. So:

• Switching apps means switching directories: only separate directories give the agent its own .cloudbase/ credentials, which is what makes "open this project, connect to that environment" reliable.
• Switching environments means switching keys: one API Key maps to one environment, and environments do not overlap.

3.2 The cost of sharing one environment

Putting several systems in one environment creates these problems:

Resource	Cost and risk
Static hosting	Apps are separated only by subpath (/student/, /teacher/). One wrong deploy overwrites another app's files.
Cloud functions	The function namespace is shared. Two apps defining login collide, and the deploy silently replaces one.
Database	Collections and tables mix together and must be told apart by prefix (t_, s_). Backup, restore, and partial export become hard.
Data safety	Least privilege is impossible. One API Key can read and write every resource in the environment, so app A cannot be stopped from touching app B's data.
Quota and billing	The platform cannot attribute resource usage, network traffic, or AI tokens to individual apps, so chargeback and cost allocation fall apart.

Both self-built agent platforms and third-party clients should therefore enforce one project, one workspace, one isolated environment. The platform edition provisions new environments on demand through APIs, which is what makes per-tenant isolation practical in production.