The compiler service is pay-per-use, and the compiler program has access to a file where it stores billing information. Let's say the name of this file is "BILL". Clients obviously cannot write into the billing file.
Now suppose a client calls the service and specifies “BILL” as the name of the output file. The service opens the output file. Even though the client did not have access to that file, the server does, so the open succeeds, and the server writes the compilation output to the file, overwriting it, and thus destroying the billing information.
Whenever a program tries to access a file, the operating system needs to know two things: which file the program is asking for, and whether the program has permission to access the file. In the example, the file is designated by its name, “BILL”. The server receives the file name from the client, but does not know whether the client had permission to write the file. When the server opens the file, the system uses the server’s permission, not the client’s. When the file name was passed from the client to the server, the permission did not go along with it; the permission was increased by the system silently and automatically.
An [bounce attack] can allow an attacker to indirectly connect to TCP ports that the attacker's machine has no access to, using a remote  server as the confused deputy.
Another example relates to personal firewall software. It can restrict internet access for specific applications. Some applications circumvent this by starting a browser with a specific URL. The browser has authority to open a network connection, even though the application does not. Firewall software can attempt to address this by prompting the user in cases where one program starts another which then accesses the network. However, the user frequently does not have sufficient information to determine whether such an access is legitimate -- false positives are common, and there is a substantial risk that even sophisticated users will become habituated to clicking 'ok' to these prompts.
Not every program that misuses authority is a confused deputy. Sometimes misuse of authority is simply a result of a program error. The confused deputy problem occurs when the designation of an object is passed from one program to another, and the associated permission changes unintentionally, without any explicit action by either party. It is insidious because neither party did anything explicit to change the authority.
The simplest way to solve the confused deputy problem is to bundle together the designation of an object and the permission to access that object. This is exactly what a capability is.
Using capability security in the compiler example, the client would pass to the server a capability to the output file, not the name of the file. Since it lacks a capability to the billing file, it cannot designate that file for output. In the cross-site request forgery example, a URL supplied "cross"-site would include its own authority independent of that of the client of the Web browser (for example, by using a YURL).