Wendy Security Baselines

Invariants any interop PR must respect, regardless of which side of the AAA contract it touches. This is a review checklist, not a design guide — for the responsibility split and two-key authority model, see wendy-aaa-interop; for cert issuance mechanics, wendy-certificates; for enrollment, wendy-device-enrollment; for device runtime behavior, wendy-device-interop.

The platform cap is cloud-immune

No cloud-plane path may ever touch the platform cap. It lives in pki-core configuration, owned by Wendy platform administration alone.

• Every mint enforces issued ≤ min(requested, tenant ceiling, platform cap) — operator, device, and signing certs alike (§8, D4).
• It is the sole bound on a compromised cloud's ability to escalate a legitimately-authenticating principal — the reason "cloud cannot authorize on its own" holds in the form that matters (§8).
• If a design routes a platform-cap change through any cloud-facing API or config surface, that is a contract violation, not an optimization.

Push signals are fail-safe only

The SSF/CAEP stream carries revoke / downgrade / deprovision / session-kill — never grants.

• A compromised node on this stream can over-revoke — a detectable, recoverable DoS — but cannot escalate by pushing a fake grant. Any authority increase stays on the in-band, two-key crypto path (§6, D2).
• Distinguish the push stream from pki-core's on-request rights query to cloud during device-side verification: that query is cloud exercising its existing authorization authority on request, still bounded by the platform cap and gated by the principal's own signature — not a second grant path (§6).
• Safe directions are all removals: auth → cloud/pki-core (deprovision, MFA revoke, group removal), cloud → pki-core (cert revoke on role change/compromise), cloud → auth (force sign-out) (§6).