Zerq Copilot
Zerq Copilot is Zerq’s built-in assistant for natural-language interaction with the platform. It is available in two governed modes:
| Mode | Who it serves | MCP surface | Where it runs |
|---|---|---|---|
| Zerq Copilot for Management | Platform operators and engineers | Management MCP | Zerq console (signed-in operations experience) |
| Zerq Copilot for Gateway | API consumers and partners | Gateway MCP | Developer Portal |
Both modes use the same interaction patterns: embedded assistant, streaming responses, tool calls, markdown, model selection, and server-persisted threads. They differ in authorization scope—operators act through their enterprise identity; consumers act through portal session + access profile credentials. LLM configuration is server-side (AI_MODELS); API keys are not exposed to browsers.
On the marketing site, both modes are summarized at /ai-copilot (anchors #operations and #gateway).
Zerq Copilot for Management
Zerq Copilot for Management provides a conversational interface to the full control plane: collections, proxies, workflows, policies, clients, profiles, credentials, observability, and audit—without leaving the Zerq console.
Opening the assistant
Select Zerq Copilot from the console (typically bottom-right). On medium and larger viewports, the assistant opens beside your current task: primary content on the left, Copilot in a right-hand column. On smaller viewports, the panel uses the area below the top bar until dismissed. Assistant replies support rich formatting (headings, lists, tables, syntax-highlighted code) with copy on messages and code blocks.
Use Retry after a failed request or on a specific assistant message to regenerate. Retry on your own message either regenerates the following assistant reply (if present) or resends the prompt when no reply arrived yet (for example after a network error). While streaming, Stop ends generation. Assistant messages appear on the left (Zerq mark); your messages on the right with your photo or initials. Choose the model from the pill left of the input (when multiple models are configured).
From md breakpoints upward, you can expand to fullscreen for heavier work (for example workflow design or log review); collapse to return to the side panel.
Closing the panel does not delete the thread—only Clear conversation (trash) does. Threads are stored on the management API (MongoDB, keyed by OIDC sub) so refresh, new tabs, and other devices signed in as the same user can resume. Retention follows your organization’s database and backup policies.
Selecting a model
When administrators configure more than one model, a model pill appears to the left of the chat input. Open it to switch models mid-conversation; the choice persists across sessions. With a single model, the pill shows its label and is not a menu.
Example prompts
- “List my API collections.”
- “What proxies exist under Payments?”
- “Create a collection Internal Auth with base path
/auth.” - “Show active clients and their policies.”
- “Which workflows attach to the payments proxy?”
- “Summarize error metrics for the last 24 hours.”
- “Show recent audit entries for policy changes.”
- “Draft a rate-limit policy at 100 requests per minute and walk me through impact.”
Supported AI providers
Any provider your administrators configure, including OpenAI, Anthropic, Google Gemini, Groq, OpenRouter, Azure OpenAI, Amazon Bedrock, Ollama, and OpenAI-compatible endpoints. Contact your administrator to add or change providers.
Data handling and permissions
Copilot acts as the signed-in user. It only reads or changes data your role allows—the same rules as the graphical console. Tool calls use the same management APIs the console uses. Threads are stored per user on the management API; your LLM vendor may have separate retention rules.
When a workflow is saved with PUT /api/v1/proxies/:id/workflow, other Workflow Builder sessions can receive live updates via SSE—see Live updates (SSE).
Capability overview (Management MCP)
| Area | Examples |
|---|---|
| Collections | List, create, update, delete, publish |
| Proxies | List, create, update, delete |
| Workflows | View, build, update, validate, test |
| Policies | List, create, update, toggle, delete |
| Clients | List, create, update, toggle, delete |
| Profiles | List, create, update, delete, credentials metadata, rotate credentials, auth type |
| Credentials | List, create, update, delete |
| Audit logs | List and view (auditor role where required) |
| Metrics | Overview, distributions, top endpoints, errors, time series |
| Request logs | List, view, delete (admin-only where applicable) |
Effective permissions follow your role (e.g. viewer read-only; editor without destructive rights unless allowed).
Limitations (operations mode)
- Actions beyond your role are rejected by the backend—not silently dropped.
- Model quality and context limits affect multi-step tasks; break work into smaller prompts when needed.
- Destructive or sensitive operations should be reviewed in the assistant’s narration before confirmation.
Zerq Copilot for Gateway
Zerq Copilot for Gateway is the optional assistant inside the Developer Portal. It uses Gateway MCP so consumers can discover assigned APIs and run controlled test calls with the same profile credentials as the Testing console—not the operator’s control plane identity.
Requirements
- Portal session — Magic-link authentication, same as the rest of the portal.
- Selected access profile — Choose a profile before using Copilot; tools and threads are scoped per profile (and client).
AI_MODELS— The portal application must have LLM providers configured (sameAI_MODELSpattern as the operations frontend). If unset, the Copilot entry point is hidden.
Page context
The service receives the current route and a short view label: on the collections list (/dashboard), the assistant knows you are browsing assigned collections; on a collection detail (/dashboard/:id), it receives collection id, name, and published endpoint count. That context is added server-side to improve relevance.
Authentication model
| Layer | Mechanism |
|---|---|
| Portal APIs | Bearer token from magic-link session on /api/v1/developer-portal/*. |
| Gateway MCP | X-Client-ID, X-Profile-ID, and the profile’s gateway credential as Authorization—aligned with the testing console and external MCP clients. |
Prompts and tool outputs are processed by the configured LLM provider under your organization’s AI and data-processing policies (treat like other AI features that handle API metadata and responses).
Persistence
Threads are stored via GET/PUT/DELETE /api/v1/developer-portal/copilot/thread, scoped by client and selected profile (MongoDB). Coordinate retention with your operations team.
Limitations (Gateway mode)
- Requires
AI_MODELSand an active profile; scope is always the consumer’s assigned APIs and credentials.