Enterprise security: think like a staff engineer
- Source
- From the Staff AI System Design course
- By
- Sourav Banerjee
- Last updated
- 8 Nov 2026
Operations and Security Failure Diagnosis
Measure authentication rejections by bounded reason, retired/unknown key rates, policy-source observation lag, epoch mismatches, stale authority denials, cross-tenant attempts, resource rejections, audit commit failure, denied provider destinations and secret-reference errors. Protect audit/read access and retention; a tenant support operator must not inherit a platform-wide dump permission accidentally.
When Alice is denied, separate expired identity, missing membership, revoked document and unavailable/stale policy internally. Externally do not confirm another tenant’s document exists. During a key rotation incident, inspect verifier cache and accepted key set before extending trust indiscriminately. During audit failure, preserve the documented disclosure policy and recover durable writes; do not route around the sink with raw prompt logs.
Threat exercises should include forged tenant headers, guessed IDs, stale allow entries, hostile readable documents, overbroad worker credentials, an unapproved provider URL, wrong-tenant secret references, and privileged exports/restores. Configuration and operational access are part of the tenant boundary. Local policy predicates do not prove production network enforcement or resistance to all model attacks.
Interview 3: Is Private Connectivity Enough?
Prompt: Every service uses a private subnet and mTLS. Can you remove per-resource policy checks?
Spoken answer: “No. Private reachability reduces exposure and mTLS identifies a workload, but neither establishes Alice’s right to a particular source. I retain trusted end-user delegation, tenant and action scope, current document checks, and approved egress. Service credentials should be narrower than an unrestricted platform principal.”
Trade-off: More explicit identity propagation complicates interfaces. Changed constraint: If a batch worker acts after Alice’s access is revoked, which identity/policy must be revalidated?
Interview 4: What Does Audit Prove?
Prompt: An allow audit event exists. Does that prove the external provider processed the request once?
Spoken answer: “It records our decision and protected resource references at a defined boundary. It does not prove remote execution or erase a lost-response ambiguity. I keep request/job/reservation IDs correlated while preserving T18.3 and T18.6 unknown outcomes. If audit commitment is mandatory before disclosure, failure must block or enter a separately designed durable buffering path.”
Trade-off: Conservative evidence requirements can reduce availability. Changed constraint: Define the incident workflow for matching audit events, provider usage and an unknown reservation without exposing source text.
Key Takeaways
- Measure authentication rejections by bounded reason, retired or unknown key rates, policy observation lag, epoch mismatches, cross-tenant attempts, audit commit failures and denied provider destinations. Protect audit read access so a support operator never inherits a platform-wide dump permission.
- Internally, separate expired identity, missing membership, revoked document and stale policy as denial reasons. Externally, never confirm that another tenant's document exists.
- A valid, unexpired signature does not authorise retrieval for a user removed yesterday. Membership, audience, policy epoch and resource access are checked separately, and stale or missing authority denies instead of promoting a cached allow.
- Private subnets and mTLS do not replace per-resource checks. An allow audit event records a decision at a defined boundary and does not prove the provider processed the request once.