# Ops-warden security-zone admission evidence — 2026-08-22

This record supports the `z1-operational` membership declared in
`tenancy.yaml`. It does not claim the M2 gates that ops-warden has not met.

## Identity and scope

- Workload id: `ops-warden`.
- Runtime binding: Kubernetes ServiceAccount
  `system:serviceaccount:ops-warden:ops-warden`, issued by railiance01 and
  verified against the enforcing flex-auth pin on 2026-08-19.
- Responsible party: `team:platform-security` in this repository.
- Scope: attended issuance of short-lived SSH certificates plus a pointer-only
  credential catalog. Secret values are not stored in the catalog or audit.

## M1 evidence

- Owned front door: `warden sign` is the sole certificate-issuance interface;
  actor inventory, principal allow-list, and TTL ceilings are enforced before
  the CA backend.
- Basic service objective: production signing is bounded by the actor TTL
  policy (`adm` 48h, `agt` 24h, `atm` 8h); `warden status` and the production
  verification records expose backend readiness.
- Data handling: `ADR-0002` makes ops-warden a transparent conduit and
  `ADR-0004`/`ADR-0007` prevent raw agent reads and fail safe on ungraded lanes.
- Policy path: `history/2026-08-19-flex-auth-caller-identity-evidence.md` proves
  the authenticated caller path and anonymous rejection. At adoption, the
  migrated real operator config reran the check successfully through the
  existing tunnel: HTTP 200, effect `allow`, decision
  `decision:f3f7c88f9585582a`.

## Why not z2

Ops-warden has security review artifacts, but not the complete M2 promotion
set: there is no SLO history, on-call rotation, or exercised signing-path
incident/recovery runbook. Its tenancy posture therefore remains V0 and its
accurate zone membership remains `z1-operational`.