API Platform Automation with Zerq Management MCP — Collections, Policies, Clients, Audit, and Metrics via Claude, ChatGPT, and CI/CD

Enlarge

Every platform engineering team carries the same list of admin tasks: onboard a new partner, publish a new API version, update a proxy upstream, rotate credentials, configure a workflow. Too repetitive to do manually at scale. Too consequential to automate carelessly.

The standard answer — a shared admin service account for CI/CD scripts — creates a problem most teams don't fully see until an incident. The credential is over-privileged, attribution in the audit log is meaningless, and the blast radius of a leaked key covers the entire admin surface. That is not automation. That is a shadow admin path.

TL;DR: Zerq Management MCP exposes your entire API platform's admin surface as MCP tools — collections, proxies, workflows, policies, clients, profiles, credentials, audit logs, and metrics. Claude (Desktop and Web), ChatGPT, Manus, Cursor, CI/CD pipelines, and any MCP-compatible client connect under the same OIDC identity and RBAC as your admin UI. AI clients authenticate automatically via OAuth discovery. No shared admin keys. One audit trail for everything.

The platform automation problem: shared keys, no attribution, no governance

Platform automation is not new. The expectation that it should have the same governance properties as manual administration is.

When a platform engineer uses the admin UI to onboard a new partner, every action is logged: who did it, what changed, when. The audit trail is complete. Compliance teams can reconstruct the change history without ambiguity.

When the same engineer writes a script to do the same thing, the governance model collapses. The script uses a service account — an admin-level key stored in a CI/CD secret, shared across every pipeline that needs it, issued to no individual. The audit log records the service account name. Not the engineer. Not the pipeline. Not the intent. For a compliance team reconstructing a change incident, the log is a gap, not an answer.

Three specific problems that compound at scale:

Overprivileged shared credentials. Service accounts for platform automation typically have full admin access because scoping them narrowly is too much friction. A pipeline that only needs to update proxy upstreams gets the same credential as one that can delete production collections. There is no least privilege. There is only one key that opens everything.

No operator attribution. When a generic service account makes a change, the audit trail cannot answer who triggered it, which deployment caused it, or what the authorised intent was. That ambiguity is a compliance liability and an incident investigation obstacle.

AI assistants can't close the gap. A platform engineer using Claude or Cursor can draft configuration, write automation scripts, and reason through complex changes — but they cannot execute admin operations through a governed interface. The result is copy-paste into the UI or paste into a script that runs under the shared service account. Neither is auditable to the individual.

The solution: Management MCP — admin operations under your existing identity

Zerq Management MCP exposes the Zerq management API as MCP tools. Claude Desktop, Cursor, CI/CD pipelines, and any MCP-compatible client connect to it and execute admin operations directly — under real identity, with real RBAC, logged to the real admin audit trail.

The connection uses the same OIDC-based authentication as your admin UI. There is no separate MCP credential. There is no special service account. The connecting client authenticates with its own bearer token, and role-based access control is enforced exactly as it is in the UI.

In practice:

• A platform engineer using Claude connects with their own OIDC session. Every action Claude takes is attributed to that engineer in the audit log.
• A CI/CD pipeline connects with a service identity scoped to the exact operations it needs — modifier access for proxies only, if that is all the pipeline does.
• An AI assistant cannot perform operations the connected identity is not authorised to perform. Viewer roles cannot write. Role boundaries are enforced at the operation layer, not the application layer.

The audit trail is unified. Management MCP operations appear in the same admin log as operations performed through the UI — same format, same detail, same queryability.

How it works: your entire API platform becomes MCP tools

Management MCP covers the full admin surface — not just routing config. Full reference in the Management MCP documentation →

Collections

List, get, create, update, delete, and toggle the published status of API collections. A collection groups related endpoints and is the primary unit of access control — partners and AI clients are granted access at the collection level.

IaC and GitOps workflows can drive collection lifecycle entirely through Management MCP: create on deploy, disable during maintenance, delete on decommission — all attributed, all audited.

Proxies

List, get, create, update, and delete proxy configurations. Each proxy defines routing rules, upstream URL, and the workflow attached to a set of endpoints within a collection.

CI/CD pipelines promoting config from staging to production update upstream URLs, apply new workflow definitions, and validate the result — without touching the admin UI.

Workflows

Get, update, and validate workflow definitions. List available workflow nodes and templates. Test individual nodes or run a full workflow to verify behaviour before applying to production.

Workflows define the processing logic — authentication checks, rate limiting, request transformation, conditional routing — attached to each proxy. Applying a standard template when creating a new proxy, or rolling out a policy change across multiple proxies, becomes a scripted operation with full change attribution.

Policies

List, get, create, update, toggle, and delete access policies. Policies define rate limit intervals and quota limits — the enforcement rules applied to clients calling your gateway.

Automating policy management means new partner tiers, quota adjustments, and rate limit changes go through the same governed, audited path as any other platform change. An AI assistant can propose and apply a new rate limit policy in one conversation, with every step logged.

Clients and profiles

Manage the full lifecycle of API clients and their authentication profiles.

Clients — list, get, create, update, toggle status, and delete API clients. Each client represents a partner, internal service, or AI integration. Assign collections and a policy on creation.

Profiles — list, get, create, update, and delete authentication profiles per client. Set the auth type (none, token, JWT, OIDC, mTLS), configure allowed methods and IP allowlists, rotate credentials on demand, and retrieve current credential state.

Partner onboarding — create client, assign collections, set policy, configure profile auth type, generate credentials — becomes a single governed sequence whether triggered by a CI/CD pipeline, a Claude conversation, or a script.

Backend credentials

List, get, create, update, and delete the credential sets used to authenticate your gateway to upstream backend services. Supports basic auth, API key, OAuth 2.0 client credentials, and mTLS certificates.

Managing backend credentials through Management MCP means rotation and updates are logged in the admin audit trail alongside every other platform change — not handled separately in a secrets manager with no governance layer.

Audit logs

Query the admin audit trail directly via MCP. Filter by actor, resource type, action, IP address, status code, and time range. Retrieve individual log entries by ID.

An AI assistant can answer compliance questions — "show me all collection deletions in the last 30 days" or "who changed the Payments proxy configuration this week" — by querying the live audit log, without anyone needing direct database access.

Metrics and request logs

Query gateway metrics: overview totals, status code distribution, HTTP method distribution, top endpoints by volume, endpoints with elevated error rates, and request volume over time — all filterable by collection and client.

Query gateway request logs with full filter support: path, status, method, client, profile, collection, latency, request/response body search. Retrieve individual log entries.

Operators and AI assistants can investigate incidents, answer SLA questions, and spot anomalies without leaving the MCP interface.

RBAC: least privilege enforced at the operation level

Management MCP enforces two roles, both derived from your existing OIDC identity:

Viewer — list and inspect resources. For read-only automation, validation steps in CI/CD pipelines, or AI assistants used to audit and report on platform state.

Modifier — create, update, and delete resources. For automation that changes platform configuration. Should be scoped to the minimum operations required — a pipeline that only updates proxy upstreams does not need collection delete permissions.

The role is determined by the connected identity, not by the MCP tool call. An attempted write operation from a viewer identity is rejected at the same enforcement layer as the admin UI — not by the client, not by convention.

See RBAC and role management →

How to connect AI clients and CI/CD to Management MCP

Management MCP is an OAuth-protected resource. It publishes standard OAuth resource metadata at /.well-known/oauth-protected-resource, which tells any compliant MCP client where your identity provider is and how to obtain a token. Any MCP client that supports OAuth discovery — Claude Desktop, Claude.ai, ChatGPT, Cursor, Manus, and others — handles the login flow automatically. You only need the endpoint URL. No Authorization headers in the config.

See Management MCP documentation →

Claude (Desktop and Web)

Add Zerq Management MCP as an MCP server in Claude Desktop settings, or connect from Claude.ai via the MCP integrations panel:

{
  "mcpServers": {
    "zerq-management": {
      "type": "http",
      "url": "https://your-gateway-host/management/mcp"
    }
  }
}

No Authorization header required. Claude fetches the OAuth metadata from the well-known endpoint, walks you through your identity provider's login flow, and obtains an OIDC token automatically. Every action Claude takes is attributed to your identity in the admin audit trail — not a service account.

What Claude can now do: answer questions about current platform configuration, propose and execute changes on confirmation, walk through multi-step onboarding sequences, and flag configuration inconsistencies — all governed, all attributed.

Cursor

Add the management MCP server in Cursor settings:

{
  "mcp": {
    "servers": {
      "zerq-management": {
        "type": "http",
        "url": "https://your-gateway-host/management/mcp"
      }
    }
  }
}

Same OAuth discovery flow — Cursor handles login automatically on first connection. Platform engineers writing IaC definitions or automation scripts can inspect live platform state, validate proposed changes, and execute safe operations from the editor without switching to the admin UI.

What Cursor can now do: read live proxy and workflow configuration to inform generated code, catch mismatches between IaC definitions and actual gateway state, and run operations like creating collections or assigning access profiles directly.

ChatGPT, Manus, and other MCP clients

Any AI client that supports MCP over HTTP and OAuth discovery connects with just the endpoint URL — the same pattern as Claude and Cursor. ChatGPT (via custom integrations), Manus, and any agent framework that implements the MCP spec will discover the OAuth server, complete the login flow, and operate under the authenticated identity.

The gateway enforces the same RBAC regardless of which client is making the request. The audit trail records the identity, not the client application.

CI/CD pipelines

Pipelines use a non-interactive service identity — there is no browser flow, so the token must be obtained and passed explicitly. The pipeline authenticates with your identity provider to get an OIDC token, then passes it as a bearer header on each request.

# Example: update a proxy upstream as part of a deployment step
curl -X POST https://your-gateway-host/management/mcp \
  -H "Authorization: Bearer $OIDC_TOKEN" \
  -d '{"tool": "manage_proxies", "action": "update", ...}'

Scope the service identity to the minimum role required — a pipeline that promotes proxy configurations needs modifier access for proxies only. Every operation is attributed to the service identity in the admin audit trail: which job, which identity, which operation.

Real platform automation use cases

Platform engineer: partner onboarding in Claude

A platform engineer asks Claude: "Onboard Acme Corp with access to the Payments and Orders collections, rate limit 1,000 requests per minute, and generate sandbox credentials."

Claude calls manage_credentials to create the client, manage_collections to assign the access profiles, and confirms the result. Each operation executes under the engineer's OIDC session and is logged individually to the admin audit trail.

The whole sequence completes in one conversation. The audit log shows the engineer's identity against each operation — not a generic service account.

CI/CD pipeline: promoting gateway config from staging to production

A deployment pipeline runs on merge to main. It reads staging proxy configuration using a viewer identity, validates the workflow definition, then uses a modifier identity to update the production proxy upstream URL and apply the updated workflow.

Every step is logged with the pipeline's service identity. If the pipeline fails midway, the audit log shows exactly which operations completed. No manual reconstruction required.

Developer in Cursor: inspecting live gateway config

A platform engineer writing a new integration asks Cursor: "What workflow is attached to the Payments proxy, and what authentication method does it enforce?"

Cursor calls manage_workflows and returns the live workflow definition — not a README copy that may be months out of date. The engineer writes integration code against what the gateway actually enforces today.

Security review: bulk credential rotation

A quarterly security review identifies credentials for a deprecated product tier that have not been rotated. An AI assistant connected to Management MCP lists the credentials, issues replacements, revokes the old ones, and confirms the result.

The full rotation is logged — which credentials, when, under which identity. That log is the compliance evidence. The review closes without a manual reconstruction.

What you do not need to build

Zerq Management MCP is part of Zerq. If you are running Zerq, the management MCP endpoint is already available. You do not need to:

• Build a separate automation API for CI/CD pipelines
• Issue a shared admin key for platform scripts
• Create a custom integration so AI assistants can access the admin plane
• Maintain a parallel logging pipeline for automation-originated changes
• Stand up additional infrastructure

The OIDC identities you already use for admin sign-on work for Management MCP. The admin audit trail already captures operations from every interface. There is no "automation layer" to build — only a client to connect.

If you are also looking to give AI clients governed access to your published APIs — not the admin plane, but the consumer APIs your partners call — that is Gateway MCP: the same credential model applied to API consumers instead of operators. See how Gateway MCP works →

See all capabilities → · gateway architecture →

The security model

Every Management MCP operation executes under a real identity — a platform engineer who authenticated via the OAuth flow, or a CI service identity with a specific scoped role. There is no privileged service account shared across clients, no admin key that bypasses RBAC, and no operation that escapes the audit trail.

The RBAC model is the same one enforced in the admin UI. A viewer cannot write. A modifier scoped to proxy operations cannot touch credentials. The gateway does not distinguish whether the operation came from the UI, a script, or an AI assistant — it applies the same enforcement to all of them.

That is the correct architecture for platform automation in a regulated enterprise: least privilege, full attribution, one audit trail.

See security and governance → · audit logging →

Management MCP — automate your API platform →

Management MCP documentation →

Security & governance →

See all capabilities →

Request a demo →