AgentHub
Documentation

Security Boundaries

AgentHub separates identity, product authorization, local execution, IM events, and model API credentials into distinct layers. Public docs describe boundaries and principles only; they do not publish production hosts, secrets, rollback paths, or private evidence.

Identity

TokenDance ID is the identity authority:

  • GitHub, Google, Feishu, and other third-party providers are managed by TokenDance ID.
  • AgentHub consumes TokenDance ID as an OIDC relying party.
  • Hub Server issues AgentHub-local sessions.
  • Low-risk Desktop/Web personalization is not Hub API authorization.

Do not describe Feishu OAuth, GitHub OAuth, or Google OAuth as direct AgentHub login.

Public website login is intentionally narrow. It can personalize the product site and prove the TokenDance ID redirect path, but it must not be treated as evidence that Hub API authorization, Edge target access, or runtime execution permissions are complete.

Authorization

After authentication, authorization is AgentHub-local:

  • whether a user belongs to an organization or project;
  • whether a user can access a workspace, device, or Edge;
  • whether a user can start, cancel, approve, or inspect a run;
  • whether a user can read diffs, artifacts, logs, and audit records.

Authorization decisions should be written to the Hub audit log, including denied actions.

Authorization should be checked at the point of action, not only at page load. Opening a project view, starting a run, approving a tool call, reading a diff, downloading an artifact, and routing to an Edge target are separate decisions and should remain independently auditable.

Secrets And Credentials

These must not appear in frontend code, card payloads, public logs, or public docs:

  • model API keys;
  • Feishu verification token, encrypt key, app secret, tenant token;
  • TokenDance ID client secret;
  • Hub session signing secret;
  • Edge local execution secrets;
  • production host paths, backup paths, and rollback commands.

TokenDance API keys authenticate model API calls. They are not AgentHub login credentials.

Use placeholders in public examples and keep real values out of screenshots. If an example needs a credential-shaped field, use names such as <agenthub_session_token>, <local_edge_token>, or <provider_api_key> and state who owns it. Do not publish real callback payloads, refresh tokens, provider responses, or local secret paths.

Local Execution And Sandbox

Edge Server sits close to the filesystem and process boundary, so it should default to conservative behavior:

  • restrict accessible directories with a workspace allowlist;
  • require approval for high-risk tool calls;
  • run runtime adapters in sanitized environments;
  • expose file changes through diffs and artifacts for user review;
  • emit events for failure, cancellation, timeout, and permission denial.

Remote/Cloud Edge, device proof, and relay/provisioning are still in development and should not be described as fully available.

Local execution should default to least privilege. The UI should surface dangerous operations before execution, Edge should enforce workspace policy even if the UI is bypassed, and adapter output should be converted into structured events before it is shown in Web, Desktop, or IM surfaces.

Feishu/Lark Security

Feishu/Lark is a collaboration entry point, not the identity system:

  • verify signatures and decrypt events before business handling;
  • respond to card.action.trigger within 3 seconds;
  • deduplicate im.message.receive_v1 by message_id;
  • keep card actions limited to action ids and business object ids;
  • route account binding back through TokenDance ID.

Long-running work should leave the webhook request path quickly. The integration gateway should acknowledge, enqueue, and then let AgentHub update the user through later card or message events. Raw prompts, full file content, provider keys, and local absolute paths should not be copied into card payloads.

Audit

Recommended audit events:

  • login, logout, session refresh, and binding state changes;
  • project membership, device, workspace allowlist, and permission changes;
  • run creation, cancellation, failure, completion, and approval;
  • tool calls, file changes, diffs, artifacts, and previews;
  • IM event handling results and external platform error codes.

Logs should not record full prompts, message bodies, secrets, or sensitive content from raw model responses by default.

A minimum useful audit record should include actor, organization/project, target Edge or workspace id, run id, action, result, timestamp, request id, and a redacted reason for denial or failure. Keep private evidence in the operator workspace; public docs should describe the shape, not the production log stream.