The Audit as a Single Chain of Evidence

The security-audit skill becomes useful when its trust map and coverage ledger are read as one chain rather than as separate documents. This synthesis connects a lower-trust action to a principal, resource, boundary, stable review unit, and evidence decision, so readers can decide whether a mapped area is ready for hunting, still needs information, or must be reported as partial.

The test is practical. Take one hypothetical action and refuse to skip a step. Suppose an ordinary tenant submits an object identifier to an export function. The security question is not simply “does the endpoint accept an ID?” It is: can this tenant cause an export containing another tenant's records, which control should bind the selection to the requesting tenant, what copies and jobs carry the result, and what can the repository or a safe local fixture actually establish?

From action to trust map

The first step is to name the action in the terms established earlier. The lower-trust principal is an ordinary tenant with permission to export their own records. The protected resource is another tenant's data and the export artifact that may contain it. The entry surface is the export request, but the important path may continue through a query, a background job, object storage, and a download route. The intended control is not merely authentication. It is a tenant- or object-level authorization decision that must survive selection, queuing, generation, and retrieval.

That description already changes the review. A component-oriented approach might inspect the export handler and stop at a visible permission check. The trust map asks what identity reaches the query, whether the object selector comes from a caller-controlled field, whether the background job preserves tenant context, and whether the final artifact is downloaded under the same authorization. If the primary query is scoped correctly but the generated file is stored under a shared key, the boundary may fail after the original check. If the export is intentionally restricted to administrators, the ordinary tenant scenario may be out of scope, but the administrator's own delegated paths still need their intended authority defined.

The same method works for a different surface. Imagine a backend that makes an authorization decision from forwarded identity metadata. The lower-trust actor may be a remote caller; the protected resource may be another account; the suspected control failure is trusting a header; and the decisive external fact is whether an untrusted peer can reach the backend or whether the ingress removes the header. The source map can show the consumption point and the authorization consequence without pretending to know the network topology.

In both cases, the map separates what is known from what is merely plausible. It also tells the reviewer which domain guidance is relevant. The export path calls for data-isolation and lifecycle reasoning. The forwarded-identity path calls for HTTP, proxy, and identity reasoning. Neither conclusion follows from a keyword alone; it follows from the boundary the map has exposed.