API gateway audit access for compliance and security teams

Enlarge

Compliance and security teams need API gateway audit access — direct visibility into what happened on your API platform: which credentials were used, who changed which configuration, and what traffic passed through during the incident window. They need that visibility on their own schedule, without filing a ticket or waiting for an operations engineer to pull a report. What they do not need is the ability to create proxies, toggle collection status, or rotate credentials. Giving them admin access to satisfy a visibility requirement creates blast radius, and creates an audit finding in itself.

The answer is a dedicated auditor access path that gives compliance teams API gateway audit access without any write permissions. This post walks through exactly what that looks like in Zerq: the auditor role, what it covers, the audit and request log formats, and how compliance teams can query and export evidence without involving platform engineers.

Why most API gateways make compliance audit access difficult

Apigee gives you IAM roles, but mapping them to a "read audit logs only" permission requires configuring custom bindings across multiple GCP services. Kong requires custom RBAC configuration through the Admin API or a Kong Manager enterprise feature. AWS API Gateway has no native audit log; you assemble evidence from CloudTrail, CloudWatch Logs, and Access Logs in three separate services, with three separate access models to configure.

The practical result is usually one of two outcomes. Either the compliance team gets admin access because it is faster to configure, and that over-provisioning becomes an audit finding the next time someone looks. Or they get a CSV export from IT once a quarter, which satisfies no one, especially not a regulator who wants to trace a specific transaction.

Neither approach gives the compliance team independent, real-time access to the evidence they need. And neither produces an audit trail for the auditors' own access: who queried audit data and when.

In banking, healthcare, and government, regulators increasingly ask for evidence of continuous monitoring, not a quarterly export. PSD2, DORA, HIPAA, and equivalent frameworks all expect the compliance function to have independent access to audit data, not mediated access through the platform team. That requires a structured, always-on access path.

The Zerq auditor role

Zerq's RBAC model has four platform roles: viewer, modifier, auditor, and admin. The auditor role is purpose-built for compliance and security teams. It provides:

• Full read access to all platform configuration: collections, proxies, clients, profiles, policies, and credentials (metadata, not secret values)
• Full audit log access: every configuration change made by any user or automation, in structured JSON
• Full request log access: every API call routed through the gateway, with request and response detail
• Metrics and dashboards: real-time and historical traffic data, status distributions, top endpoints, error rates

The auditor role cannot create, update, delete, or toggle any resource. It cannot rotate credentials. It cannot modify any policy or workflow. It is structurally read-only, enforced at the API layer, not just through UI controls.

This separation of duties matters for compliance frameworks that require independent audit oversight. The same person who can change the platform configuration should not be the only person who can read the audit log of those changes.

What the auditor does not see

Secret values in credentials are never exposed to any role, including admin. An auditor with access to the credentials section will see credential type, creation date, last rotation date, and which proxies reference the credential, but not the actual API key, certificate private key, or connection string. Secret management operates on a write-only model for sensitive values.

What the audit log contains

Every configuration change in Zerq generates a structured JSON audit entry stored in the customer's own MongoDB instance. This covers creating a proxy, updating a policy, deleting a client, and rotating credentials. Here is what a typical entry looks like:

{
  "timestamp": "2026-06-01T09:23:14Z",
  "actor_id": "auth0|platform-engineer-001",
  "actor_type": "user",
  "action": "UPDATE",
  "resource_type": "policy",
  "resource_id": "6649f2a1b3c4d5e6f7890123",
  "method": "PUT",
  "url": "/api/v1/policies/6649f2a1b3c4d5e6f7890123",
  "ip": "10.0.1.42",
  "user_agent": "Mozilla/5.0 (compatible; ZerqManagementUI/2.1)",
  "request_id": "req_01hwk3m9p4n8q",
  "request_body": {
    "rate_limit_requests": 500,
    "rate_limit_interval": "1m"
  },
  "response_status": 200
}

Each field serves a specific compliance function:

The audit log covers every resource type: collections, proxies, clients, profiles, policies, credentials, and workflow configurations. It also logs Management MCP tool calls: a Copilot action that creates a proxy generates the same audit entry as a manual UI action, under the same actor identity.

What the request log contains

The request log is separate from the audit log. Where the audit log records configuration changes, the request log records every API call routed through the gateway. Each entry captures:

• Request ID (unique trace ID, also sent back as X-Request-ID to the caller)
• Timestamp
• HTTP method and path
• Target backend URL
• Response status code
• End-to-end latency in milliseconds
• X-Client-ID and X-Profile-ID headers (which partner or application made the call)
• Client IP address
• Full request headers and body
• Full response headers and body

For financial services, this is the per-transaction audit trail. For healthcare, it is the record of which client accessed which FHIR resources and when. For any incident response, it is the data that lets you reconstruct exactly what passed through the gateway during a window of concern.

Request logs are filterable by path (with wildcard support), HTTP method, status code, latency threshold, client ID, and time range. An auditor can filter to a specific partner's traffic on a specific day, export it, and hand it to a regulator without involving the operations team.

Querying audit data through the Management MCP

Compliance teams who prefer scripted, automated evidence collection can use the Management MCP directly. The auditor role has access to two audit tools:

• list_audit_logs: returns a filtered list of audit entries with pagination
• get_audit_log: returns the full detail of a single audit entry by ID

An automated weekly evidence export might look like:

# Query all policy changes in the last 7 days via Management MCP
POST /api/v1/mcp
Content-Type: application/json
Authorization: Bearer <auditor-oidc-token>

{
  "jsonrpc": "2024-11-05",
  "method": "tools/call",
  "params": {
    "name": "list_audit_logs",
    "arguments": {
      "resource_type": "policy",
      "action": "UPDATE",
      "from": "2026-05-25T00:00:00Z",
      "to": "2026-06-01T00:00:00Z"
    }
  }
}

The Management MCP runs under the auditor's own OIDC session. Every query made through it appears in the audit log with actor_type: user and the auditor's identity, giving you a complete record of who accessed audit data and when. There is no back channel that bypasses the audit trail.

Step-by-step: running a configuration change audit

1. Sign in to the management UI with auditor credentials (or use an OIDC token directly with the Management MCP).
2. Navigate to Audit logs in the sidebar. This section is visible only to the auditor role.
3. Set the time range for the review period (for example, the previous calendar month).
4. Filter by action: DELETE and action: UPDATE to see substantive changes.
5. For each change of interest, open the full entry to see the request_body: the exact payload submitted at the time of change.
6. Filter by resource_type: credential to isolate credential creation and rotation events.
7. Cross-reference with request logs filtered to the same time window to correlate configuration changes with traffic anomalies.
8. Export the filtered view as JSON for SIEM ingestion or regulator submission.

All of these steps are available to the auditor without contacting the platform team.

SIEM integration and data residency

Zerq stores all audit and request data in the customer's own MongoDB instance. No audit data reaches Zerq's infrastructure at any point; the data residency boundary is entirely within the customer's environment. For teams under frameworks that require data to remain in a specific region or perimeter (GDPR, HIPAA, government boundary policies), this is the expected model. The deployment architecture places the full audit data store and every request log inside the customer's infrastructure boundary.

For SIEM export, structured JSON from MongoDB can be forwarded to any SIEM using standard MongoDB change streams or a scheduled export pipeline. The log format is consistent and documented, so field mappings to Splunk, Sentinel, Elastic SIEM, or any other platform are straightforward. Because audit and request logs use the same field schema across all resource types, a single SIEM parser handles the full log stream.

What this looks like for a compliance review

A European bank running Zerq for their open banking infrastructure needs to demonstrate DORA compliance to their regulator. The compliance team (separate from platform operations) has been assigned the auditor role in Zerq. When a DORA audit is initiated, the compliance team runs the following independently:

They filter the audit log to the previous 12 months, grouped by resource_type: credential, to show all credential rotation events and confirm they fall within the mandated rotation schedule. They pull request logs filtered by status: 5xx to produce an uptime and error rate report for the audit period. They export all action: DELETE events to confirm that any deprovisioned partner access was formally removed rather than deactivated, and that the removal is traceable to a named actor with a timestamp.

All of this takes the compliance team less than an hour, without a single ticket to the platform team. The evidence is in structured JSON, traceable to individual identities, and stored in the bank's own infrastructure, never in a vendor's system.

For the auditor's own access activity, the same audit log records their queries. The compliance function's access to audit data is itself audited. That audit-of-auditors record is available to senior oversight roles if needed.

Compliance evidence checklist

For regulated API platforms, compliance teams typically need evidence across several categories. Here is where to find each in Zerq:

• Change control records: audit log filtered by action: CREATE, UPDATE, DELETE; includes the full payload of every change
• Credential rotation evidence: audit log filtered by resource_type: credential, action UPDATE; confirms rotation dates and actor
• Access deprovisioning: audit log filtered by resource_type: client, resource_type: profile, action DELETE or UPDATE with active: false
• Per-transaction trail: request log filtered by client_id and time range; includes method, path, status, latency, and headers
• Configuration snapshots: read access to all current configuration via collections, proxies, policies; no separate export needed
• Anomalous access: request log filtered by status: 4xx and status: 5xx by client, with IP and timestamp
• Non-human traffic: request log with X-Gateway-Source: mcp filter isolates AI agent traffic from traditional REST calls

Summary

Zerq's auditor role gives compliance and security teams direct, independent access to the full API platform audit trail covering configuration changes, request-level traffic records, and credential lifecycle events, without any ability to modify the platform they are auditing. Every piece of evidence is in structured JSON stored in the customer's own MongoDB instance, with no data leaving the perimeter. Auditor queries are themselves logged under the auditor's identity. SIEM integration uses standard MongoDB output with a consistent log schema. Compliance reviews that previously required IT operations involvement can run end-to-end on the compliance team's own schedule.

Zerq is an enterprise API gateway built for regulated industries — one platform for API management, AI agent access, compliance audit, and developer portal, running entirely in your own infrastructure. See how it works or request a demo to walk through your specific requirements.