Spotting Authentication and Authorization Gaps in an Integration Design

Evaluating a whole integration, not one control

This is the evaluate-level capstone of the authentication and authorization task statement. Instead of reasoning about a single control, you review a described integration architecture end to end and separate the parts that are genuinely sound from the parts that are real security gaps. The discipline cuts both ways: miss a gap and you approve a leaky design; flag a sound element and you waste effort and lose credibility. The exam rewards precise discrimination, not blanket suspicion.

The review is organised around a small checklist of where gaps typically hide: the identity source, tenant key isolation, and downstream logging. Each maps to a knowledge point earlier in this task statement, so the capstone is really about applying them together against a concrete diagram.

The three gaps to check for

Three checks catch most integration gaps. First, the identity source: is identity established server-side from the authentication layer, or is it a user-asserted claim read from a message or client payload? A capability check based on "I am a premium customer" in the user message is a gap; a server-side authentication layer in front of the API is not. Second, tenant key isolation: does each tenant have its own API key, or is one shared key used for all tenants? A shared key is a gap; per-tenant storage isolation at the data layer is a sound element. Third, downstream logging: does the Claude response flow into a downstream system with a log at the integration boundary, or does it hand off unlogged?

Running these three checks over a diagram gives you a structured pass rather than an impressionistic one. Each item has a clear sound-or-gap answer grounded in the earlier knowledge points.

Sound elements you must not flag

The trap that separates strong candidates from weak ones is over-flagging. A diagram full of components invites the reflex to mark everything as a risk, but several elements are deliberately correct and flagging them is itself a mistake. A server-side authentication layer in front of the API is the right way to establish identity, so it is sound. Per-tenant data isolation at the storage layer is the right way to keep tenants' data separate, so it is sound. Marking these as problems signals that you are pattern-matching on "security-related component" rather than evaluating whether each element is correct.

Getting the sound elements right is as much of the skill as catching the gaps. The credited review leaves the good design alone and spends its attention on the parts that are actually wrong.

The unlogged downstream handoff

One gap deserves special emphasis because it is the one most often missed: a Claude response passed to a downstream system, a CRM, a system of record, a workflow engine, with no logging at the integration layer. It is easy to overlook because everything upstream can be immaculate: server-side identity, per-tenant keys, tenant data isolation. None of that rescues the handoff. If the output crosses into a downstream system unlogged, there is no record of what was sent, which means an incident on that path cannot be reconstructed. The gap is independent of how correctly identity was established upstream; a perfect front end does not make an unlogged handoff acceptable.

This is both a security and an observability gap, and it foreshadows observability as a precondition for agent autonomy: an action taken but not logged is, to a reviewer, an action that cannot be allowed.

What the exam trips candidates on

The two traps are the two ways the review goes wrong. The first is flagging every component in an integration diagram as a problem without distinguishing sound design from actual gaps, which is over-flagging. The second is missing that a response passed to a downstream system with no logging is a security and observability gap, which is under-flagging the subtlest item. The credited answer marks the user-asserted identity source, the shared tenant key, and the unlogged downstream handoff as gaps, and leaves the server-side auth layer and per-tenant isolation unflagged.

Common misreadings to avoid

How this shows up on the exam

Expect a labelled integration diagram with a mix of sound and flawed components and a 'select every problem' framing. The reliable reading is to check identity source, tenant key isolation, and downstream logging, flag the user-asserted identity, the shared tenant key, and the unlogged handoff, and leave the server-side auth layer and per-tenant isolation unflagged. This capstone draws on server-side identity injection, user-asserted role claims, and multi-tenant API key isolation, and it points forward to observability as a precondition for agent autonomy.