A PDF renderer fetches whatever URL a user's render job names, including the instance metadata endpoint. What threat do you raise?

## Reading the design The design has a user-facing submission path, a rendering process, and an outbound fetch from that process to whatever the job's HTML references. Draw the boundary where the render job crosses from the requester into the renderer, and then ask the question that finds confused deputies: **does this process act on input from a less-privileged source while holding authority that source lacks, without checking on whose behalf it acts?** Here the answer is yes on every clause. The requester is an authenticated but low-privilege customer. The renderer sits inside the deployment with a network position no customer has, and the instance metadata endpoint will hand out credentials for the identity the workload runs as. Nothing in the fetch consults the requester's rights. ## Why this is Elevation of Privilege, not Information Disclosure Both letters can be argued, and the argument is the interview. Information Disclosure names the payload: secrets end up in a rendered document. Elevation of Privilege names the mechanism: an actor performed an action - retrieve workload credentials - that it was never permitted to perform, by borrowing the authority of a process that was. Choose the category that leads to the right mitigation. If you file this as disclosure, the tempting fixes are about the output: redact the PDF, scan for secret-shaped strings. If you file it as elevation, the fix is about authority, and it also covers the cases where the fetched target is not a secret at all - an internal admin endpoint that performs a write, a health or control interface, a peer service that trusts anything originating inside the deployment. The same missing check produces all of them, which is what makes elevation the better label. The well-known vulnerability name for the mechanism is server-side request forgery; the *modeling* concept underneath it is the confused deputy, and the confused deputy is the pattern you should be able to spot in designs that have nothing to do with fetching URLs. ## What a confused deputy actually is A deputy is any component that acts for someone else while holding authority of its own. It becomes confused when it uses **its** authority to satisfy **their** request without deciding whether their rights cover it. The attacker needs no exploit; the deputy is working exactly as built. Three ingredients are always present: 1. Ambient authority - a credential, token or network reachability the process carries implicitly on every operation, not one supplied per request by the caller. 2. A less-privileged caller whose input steers what the deputy does with that authority. 3. No decision anywhere that maps the caller's rights onto the requested operation. Remove any one of the three and the threat dies, which is what makes this a productive category: it hands you three independent places to cut. ## Controls, strongest first **Remove the ambient authority from the fetch path.** Perform outbound job fetches from a component that has no workload credentials reachable and no privileged position - a separate process or network path whose reachability is the public internet only. This kills ingredient one and does not depend on getting a parser or a URL check right. **Constrain what a job may name, deny by default.** An allow-list of destinations for a render job is far stronger than a block-list of internal ranges, because block-lists have to anticipate every alias, redirect and rebinding trick that resolves back inside. **Make the caller's authority travel with the request.** Where the fetch genuinely must reach something internal, it should be authorized against the requester's rights rather than the service's, so the deputy can no longer lend out more than the caller has. **Detect.** Alarm on the renderer reaching destinations no legitimate job needs, and treat any use of the workload credential from an unexpected code path as an incident signal. This is a detective control - useful, but it does not answer the threat on its own, and a model that offers only this has not mitigated anything. ## Rating and follow-on Do not stop at "credentials leaked". The severity of an elevation threat is the reach of the authority that was borrowed, so the model should carry the follow-on: what does the workload identity authorize, and what would an attacker holding it be able to read, change or destroy? That question usually produces a second finding - the workload identity is broader than the renderer's job needs - and that finding is worth as much as the first. ## The generalisation worth taking away Any process that accepts an instruction from a less-privileged source and then performs work under its own standing authority is a candidate deputy: a webhook dispatcher, an import or export job, a template engine that can include remote resources, a callback handler, an admin utility that takes a target identifier. When you walk a diagram, the deputy test is faster than trying to enumerate techniques - compare the authority of the caller with the authority of the callee at every crossing, and look for a missing decision in between.