Skip to content

Safe actions across chat, MCP, and Windows integration

Web chat and MCP use the same capability catalogue and versioned domain services. Reading and writing therefore follow the same project, role, object, and version checks. Supported domains include the test library, requirements, planning, execution, results, reviews, relations, defects, attachments, release and change knowledge, administration, and Word import or export.

An AI answer or MCP preview does not change project data. Writes are prepared, reviewed, explicitly confirmed, and audited.

Prepare, review, commit, and audit

  1. Prepare: Chat or MCP turns the requested domain operation into a concrete, permission-checked preparation.
  2. Preview: Review the target, proposed change, effects, warnings, and—where relevant—the expected object version.
  3. Commit: Confirm only an unchanged preview that you understand. Restart after an expiry or version conflict.
  4. Audit: Review the result, deep link, and audit record. Idempotency prevents a technical retry from silently applying the same change twice.

Missing permission, stale version, unknown capability, or invalid arguments fail closed rather than applying a partial update.

Configure MCP with least privilege

MCP uses JSON-RPC 2.0 at POST /mcp. Personal project API keys operate with the roles and permissions of their active project user. Global administrative keys are separate; a global key needs an explicit additional approval before it can access project tools.

  • Create keys in the intended MCP API-key administration and copy the secret immediately; it cannot be displayed again.
  • Use a short lifetime, minimal scopes, and a clear purpose.
  • Pass the project unique ID or an approved project path instead of relying on an implicit global context.
  • Inspect the tool catalogue and capability explorer before automating an operation.
  • Revoke keys that are no longer required or may have been exposed.

Local Bridge and controlled local actions

Zeta Test Local Bridge connects supported web workflows to controlled local Windows functions. The web server cannot start arbitrary local processes. Chrome or Edge communicates through the browser extension with an installed Native Messaging host, while a machine-level policy permits only named, typed actions.

  1. An administrator deploys the Native Host and browser extension, then connects only the intended ZTM website.
  2. Customer IT defines approved process actions in the Local Bridge policy. Free command lines and legacy Lua remain blocked in the web client.
  3. External tools use a structured reference such as ztm-local-bridge:action-id. Only an installed and policy-approved action can run.
  4. Use administration to verify status, version, checksum, endpoints, and the generated Chrome or Edge policy values.

Treat the extension, Native Host, site association, and local policy as one security boundary. A connected bridge does not replace project or object permissions.