Security at z-gateway

z-gateway is designed to sit between AI agents and the tools they call. Runtime policies help determine whether a tool action should be allowed, monitored, approved, or blocked before it reaches connected systems such as GitHub or Postgres.

Agents authenticate to z-gateway with credentials intended for scoped runtime access. This keeps governance centered at the gateway and reduces the need to place broad, durable service credentials directly into agent clients.

For GitHub workflows, z-gateway uses a GitHub App installation model so access can be scoped to selected repositories and permissions. Agents authenticate to z-gateway, and z-gateway mediates the connected GitHub action according to workspace policy.

Database connectors store DSNs encrypted, validate public hosted Postgres targets, and route agent access through governed MCP tools. z-gateway does not expose raw connection strings, raw SQL, or credentials in compact dashboard surfaces.

z-gateway records runtime decisions to help teams understand what an agent attempted, how policy was applied, and what outcome occurred. Runtime sessions group related GitHub and database actions into one execution timeline, while detailed logs retain redacted evidence for rollout, troubleshooting, and security review.

Enforce-mode usage is checked against plan limits. If an enforce quota is exhausted, z-gateway records the quota reason and the dashboard shows the workspace as Enforce Paused rather than silently changing the configured mode.

z-gateway is built to limit unnecessary exposure of sensitive data in agent workflows. Public documentation intentionally avoids detailed descriptions of internal storage, signing, and key-management mechanics.

If you are an early access user and believe you have found a security issue, report it to security@z-gateway.com with enough detail for the team to reproduce and assess the issue. Please avoid public disclosure until we have had a reasonable opportunity to investigate.