Skip to main content

Enterprise Agent Platform Integration

This guide is designed for enterprise IT teams and platform integrators. It explains how to seamlessly connect CloudBase Serverless capabilities with your proprietary Agent platform, internal instant messaging tools (such as WeCom), or custom AI workbenches.

1. Division of Responsibilities​

A production-grade enterprise integration requires a clear separation of concerns between your existing infrastructure and CloudBase's sandboxed environment.

The standard division of responsibilities is mapped below:

DimensionWhat CloudBase HandlesWhat Your Enterprise Platform Handles
Environments & ComputeProvisioning and managing isolated, tenant-specific sandboxes (Databases, PG, Functions, Static Hosting) at scale via programmatic APIs.Maintaining the enterprise mapping table linking your internal user/team IDs to specific CloudBase environment IDs.
Identity & AuthGenerating and verifying granular environment API Keys and temporary credentials (STS).Handling user single sign-on (SSO), and securely routing/injecting credentials without exposing them to the front-end.
Audit & GuardrailsProviding 36 out-of-the-box MCP tools; enforcing physical row-level security (RLS) inside the Database.Capturing detailed execution logs (who ran what SQL/Function and when) and holding sensitive write operations for approval.
Agent ConstraintsOffering prompt hooks, tool metadata manifests, and custom skill injection.Writing enterprise-specific expert packages, governing team skills, and enforcing infrastructure policies via system prompts.

2. Directory Isolation and Multi-Environment Key Delivery​

In an enterprise environment where multiple applications are developed, developers should never manually copy long-term credentials or switch environment configurations.

2.1 Workspace Directory Isolation (One App, One Workspace)​

An AI Agent operates within the scope of its active workspace directory and cannot traverse subdirectories or guess path relationships on its own.

📁 Enterprise_Workspace/
  ├── 📁 App_A/   (Root for App A - linked to Env_A config)
  │    ├── .workbuddy/
  │    └── src/
  └── 📁 App_B/   (Root for App B - linked to Env_B config)
       ├── .workbuddy/
       └── src/
  • Rule: Every application must be mapped to an independent, top-level project directory.
  • Anti-pattern: Placing multiple applications under a single workspace. This causes the Agent to share the same credential envelope, leading to database and function naming collisions.

Side Effects of Sharing a Single Environment​

If you compromise on environment isolation and pack multiple projects into one CloudBase environment, expect the following trade-offs:

ResourceShared Environment Behavior & Risks
Web HostingFiles are overwritten if they share paths. A single deployment slip can overwrite another app's frontend.
Cloud FunctionsNaming collisions occur. If two apps define a function named payment-callback, they will overwrite each other.
DatabaseTables and schemas are mixed. Isolation must be managed manually via naming prefixes (e.g., app_a_users).
PermissionsGranular access control is lost. A single API Key grants absolute write access to all resources inside the environment.
Quotas & LogsUsage limits and execution logs are aggregated, making it impossible to audit per-app costs or debug isolated issues.

2.2 Built-in Local Callback Auth (No-Key Entry)​

To eliminate manual key copying and pasting (which risks exposing API Keys in prompt histories or local chat logs), platforms can implement a local OAuth loop.

[User]                 [Local Helper]             [Auth Server]             [Credentials]
  │                          │                          │                         │
  ├─ "Connect CloudBase" ───>│                          │                         │
  │                          ├─ Start Local HTTP Server │                         │
  │                          │  (127.0.0.1:4001)        │                         │
  │                          │                          │                         │
  │                          ├─ Open Browser ──────────>│                         │
  │                          │                          ├─ User authenticates     │
  │                          │                          │  & picks environment    │
  │                          │<─ Redirect with query ───┤                         │
  │                          │   (?envId=...&apiKey=...)│                         │
  │                          │                          │                         │
  │                          ├─ Exchange for STS ────────────────────────────────>│
  │                          │  (POST /capi/credential)                           │
  │                          │<─ Return Temp Tokens ──────────────────────────────┤
  │                          │                                                    │
  │                          ├─ Write ~/.config/.cloudbase/auth.json ─────────────>
  │                          │                                                    │
  ├─ Success message ────────┤                          │                         │

Callback Mechanism Steps​

  1. Helper Initialization: The local Helper (a self-contained script embedded in your enterprise Agent or workspace) starts a temporary HTTP server on a random local port (e.g., 127.0.0.1:4001).
  2. Authentication Redirect: The Helper opens the user's default browser pointing to: 
    https://tcb.cloud.tencent.com/login?cliAuth=1&_redirect_uri=http%32F%2F127.0.0.1%3A4001
  3. Silent Handover: The user signs in and selects their environment. The authentication portal redirects back to the local server, handing over the envId and apiKey in the query string.
  4. Token Exchange & Write-back: The local Helper intercepts the parameters, requests temporary STS tokens via POST /capi/credential, writes the credentials securely to ~/.config/.cloudbase/auth.json (chmod 600), and terminates the temporary server.
  5. Activation: The client Agent reloads and reads the fresh credentials. The user never sees or copies the raw API Key.

2.3 STS Temporary Token Exchange​

If your platform prefers server-side credential management over local client callbacks, your API Gateway should retrieve and dispatch short-lived STS tokens (valid for 30 minutes) using the environment's apiKey.

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>"}'

Response:

{
  "code": 0,
  "data": {
    "TmpSecretId": "AKID...",
    "TmpSecretKey": "...",
    "Token": "...",
    "ExpiredTime": 1787036755
  }
}

The exchange script must multiply ExpiredTime by 1000 to convert it to a millisecond timestamp (tmpExpired) before saving it to auth.json:

{
  "credential": {
    "tmpSecretId": "AKID...",
    "tmpSecretKey": "...",
    "tmpToken": "...",
    "tmpExpired": 1787036755000,
    "envId": "<envId>",
    "authSource": "api_key",
    "apiKey": "<apiKey>"
  }
}

3. Gateway Integration and Operations Auditing​

Enterprise compliance demands that Agent tool calls are tracked and auditable.

[Agent Tool Call] ──> [Platform API Gateway] ──> [Audit / Filter] ──> [CloudBase API]
                             │
                             └─ Log: User UIN | Action: sql/call | Query: ...

By intercepting and wrapping the MCP Server's standard tools/call transport, your gateway can enforce enterprise constraints before forwarding payloads to CloudBase:

  • Action auditing: Parse tools/call arguments to extract executed SQL queries, file write paths, or deployed cloud function names. Tag these actions with the employee's internal UIN.
  • Write operation approval: Intercept destructive operations (e.g., executing schema modifications or database resets). Put the Agent's execution on hold, dispatch an approval card to the manager's IM, and resume execution only after approval.

4. Constraint Enforcement (Constraining the Agent)​

An Agent should never have unchecked freedom. You must constrain its choices at both the system prompt layer and the physical resource layer.

4.1 System Prompt Enforcement (VPC-Only Cloud Functions)​

When an Agent writes or deploys a Cloud Function, it may default to public network configurations. You can override this behavior by injecting custom instructions at the system prompt layer.

Custom Prompts Configuration (e.g., .cursorrules)​

# CloudBase Compute Policies

All Cloud Functions created or updated by this Agent must be bound to the corporate intranet VPC.
When invoking the `createFunction` or `updateFunction` tools, you must strictly populate the `VpcId` and `SubnetId` parameters with the following values:

- VpcId: vpc-abcdefg
- SubnetId: subnet-123456
- Region: ap-shanghai

Do not deploy functions with empty or public-only network parameters.

4.2 Restricting Access via Database Row-Level Security (RLS)​

提示词（System Prompts）可以被**用户提示词注入（Prompt Injection）**绕过。真正可靠的安全策略，必须下沉到物理资源层。

For NoSQL or PostgreSQL databases, you must configure security rules or Row-Level Security (RLS) policies at the Database layer to prevent tenant cross-talk:

-- PostgreSQL Row-Level Security (RLS) Rule
CREATE POLICY user_tenant_isolation ON corporate_records
    FOR ALL
    USING (tenant_id = current_setting('request.jwt.claim.tenant_id', true));

This ensures that even if the Agent is manipulated into requesting records from another tenant, the underlying Database engine blocks the read at the physical layer.

5. Summary Checklist​

When verifying your enterprise platform's integration, check the following criteria:

  • Zero-Key Handover: Are developers authenticating via local loops or STS tokens? Ensure no long-term API Keys are pasted into chat threads.
  • Workspace Boundaries: Do projects live in isolated directories?
  • Gateways & Audit: Are tool calls intercepted, parsed, and logged under the employee's internal identity?
  • Compute Compliance: Are system prompts enforcing secure, corporate network parameters (such as VPC-only bindings) on deployments?
  • Data Fortification: Are Row-Level Security (RLS) rules active on the Database engine to guard against Agent manipulation?