A developer asks an assistant to repair a failing customer search query. The suggested patch makes the test pass, but replaces the tenant-scoped filter with a lookup by customerId alone. After the pull request merges, a user who knows another tenant’s identifier receives that customer’s record. The attacker did not need access to the repository, CI system, or coding assistant. The attacker only used a normal application request against an endpoint whose authorization check had silently disappeared.
An untrusted change is any proposed code, dependency, configuration, or workflow edit that has not yet passed controls independent of its author. Assistant output belongs in that category even when it compiles, has a plausible explanation, and fixes the reported defect. The assistant generated text from the prompt and repository context. Neither property proves that the resulting query preserves the application’s tenant boundary.
The relevant path crosses several boundaries. The assistant’s patch, its suggested package version, and any generated configuration enter the repository as untrusted artifacts. CI examines the proposed change but does not automatically establish that authorization is correct. Production executes only the merged artifact, where the missing filter exposes one customer’s data to another tenant. The following boundary map keeps those artifacts distinct:
The boundary map shows why the course uses one security contract. Treat every AI-produced artifact as untrusted until independent human review and required automated checks accept the change. The model is never the enforcement point. A prompt that asks for tenant isolation is a preference carried through the same channel as the suggested code, not a control that blocks an unsafe merge.
For the customer-search patch, the pull request reviewer checks whether the query still applies the authenticated user’s tenant entitlement. CI checks different evidence: source analysis inspects implementation patterns, dependency analysis inspects the newly added package, and secret scanning inspects changed source and configuration for credentials. Repository branch protection enforces the merge decision by requiring those checks and approvals. No control should rely on the assistant claiming that the patch is safe.
Exam rule
AI-generated code is accepted only when independent review and required security gates produce recorded evidence. Model output and prompt wording do not enforce access control.
Each control has a limit. Review can miss a subtle data-flow error, so automated checks provide another signal. A scanner can miss authorization logic that requires application context, so qualified review remains mandatory. A passing pipeline does not prove absence of vulnerabilities. It proves that the defined gate evidence exists for this revision. When a required gate fails, the repository records the finding, blocks merge according to policy, and preserves an audit trail for the acceptance or exception decision.
The running artifact is a pull request that adds GET /search?q=... to a multi-tenant web service and adds a text-search dependency. A user request is untrusted input. The handler receives the authenticated user’s identity, builds a database query, and must apply that user’s tenant entitlement before the database returns rows. The database operation runs under the application’s service identity, while the query or policy layer enforces what the end user may see. If the new endpoint accepts a tenantId from the request without comparing it to the authenticated entitlement, the blast radius is every record reachable through that service identity.
The pull request itself is also untrusted. Its diff may remove the tenant predicate, its dependency manifest may introduce a vulnerable or inappropriate package, and its generated configuration may contain an exposed secret. The assistant’s explanation cannot settle any of those questions. Evidence comes from the diff, the changed dependency manifest, the scanner categories, reviewer approval, and the merge record.
A static application security test scans source code and code-level data flow for known weakness patterns. Software composition analysis examines dependencies and component metadata for supply-chain conditions. Secret scanning searches changed repository artifacts for credentials or tokens that must not be committed. These checks inspect different artifacts, so one passing result cannot substitute for another. The request path and CI path show where suggestions originate and where verification produces acceptance evidence: