Keyring
ReferenceControl-plane API

Policy feed

What the SDK polls: the snapshot and the delta.

Generated from packages/api/src/policy/policy.controller.ts by packages/docs/tools/generate-reference.mjs. Do not edit by hand: src/reference.spec.ts regenerates it and fails on a difference.

The policy distribution feed: the endpoints that make "zero network requests on the hot path" true rather than aspirational (report section 2.7).

Everything here is a read. No handler writes an audit row, and none takes the per-workspace advisory lock that keyring.audit_log_link does, because a vendor's own control-plane write traffic must never be able to stall the feed that keeps their fleet verifying -- that is the 22.7 s stall the week 2 review reproduced, and the reason config.ts grew timeouts.

The one write is the node watermark, and it is conditional: a node that is up to date and was seen recently writes nothing (see recordNodeAck).

GET /v1/policy/snapshot

Answers 200 on success.

Authentication.

  • A krsk_ secret key only. A person's session is refused on this plane.

Query. Validated by this schema, from the control plane's own source:

const SnapshotQuery = z.object({
  project_id: z.uuid(),
  env: Env.optional(),
  tenant_id: TenantIds,
  node: NodeId.optional(),
  max_keys: MaxKeys,
  cursor: z.string().min(1).max(512).optional(),
});

Report section 6.1's first and largest fix: a host node needs the keys of the tenants that call it, not every key in the project. Narrowing is what keeps a 1 M-key project from being a 267 MB response and 555 MiB of someone else's heap.

On the delta route too, and that is the PR 4 review's finding 8a. The fallback there hardcoded null and the SDK never sent the parameter, so the one request where narrowing matters most -- a node far enough behind to need a re-seed -- was the one request that received the whole project.

const TenantIds = z
  .union([z.uuid(), z.array(z.uuid()).min(1).max(50)])
  .optional()
  .transform((value) =>
    value === undefined ? null : Array.isArray(value) ? value : [value],
  );

Matches policy_node_id_shape in migration 0005. The node id is chosen by the SDK and is therefore untrusted input: it is constrained here so that a malformed one is a 400 rather than a constraint violation, and it is only ever a bound parameter.

const NodeId = z.string().regex(/^[A-Za-z0-9._:-]{1,128}$/);

The caller's statement that it understands a paged answer, and how large a page it wants. Clamped to policySnapshotMaxKeys server-side, so asking for more is not a way around the ceiling.

Its presence is the protocol version. Absent, an oversized snapshot is a 413 that names the two ways out rather than a first page the caller would take for the whole set -- see snapshotTooLarge.

const MaxKeys = z.coerce.number().int().min(1).optional();

GET /v1/policy/delta

Answers 200 on success.

Authentication.

  • A krsk_ secret key only. A person's session is refused on this plane.

Query. Validated by this schema, from the control plane's own source:

const DeltaQuery = z.object({
  project_id: z.uuid(),
  since: z.coerce.number().int().min(0),
  env: Env.optional(),
  tenant_id: TenantIds,
  node: NodeId.optional(),
  max_keys: MaxKeys,
});

Report section 6.1's first and largest fix: a host node needs the keys of the tenants that call it, not every key in the project. Narrowing is what keeps a 1 M-key project from being a 267 MB response and 555 MiB of someone else's heap.

On the delta route too, and that is the PR 4 review's finding 8a. The fallback there hardcoded null and the SDK never sent the parameter, so the one request where narrowing matters most -- a node far enough behind to need a re-seed -- was the one request that received the whole project.

const TenantIds = z
  .union([z.uuid(), z.array(z.uuid()).min(1).max(50)])
  .optional()
  .transform((value) =>
    value === undefined ? null : Array.isArray(value) ? value : [value],
  );

Matches policy_node_id_shape in migration 0005. The node id is chosen by the SDK and is therefore untrusted input: it is constrained here so that a malformed one is a 400 rather than a constraint violation, and it is only ever a bound parameter.

const NodeId = z.string().regex(/^[A-Za-z0-9._:-]{1,128}$/);

The caller's statement that it understands a paged answer, and how large a page it wants. Clamped to policySnapshotMaxKeys server-side, so asking for more is not a way around the ceiling.

Its presence is the protocol version. Absent, an oversized snapshot is a 413 that names the two ways out rather than a first page the caller would take for the whole set -- see snapshotTooLarge.

const MaxKeys = z.coerce.number().int().min(1).optional();

Shared validators

Defined once in packages/api/src/validation.ts and used by the schemas above.

const Env = z.enum(['live', 'test']);

On this page