> ## Documentation Index > Fetch the complete documentation index at: https://agentconcepts.io/llms.txt > Use this file to discover all available pages before exploring further. # proxy > A stand-in that controls access to a real subject while preserving the subject's interface; the client thinks they're talking to the subject directly, but the proxy intercepts. computer-science law # Proxy ## Description A proxy is a stand-in that preserves the subject's interface but interposes itself between client and subject. From the client's perspective the proxy is indistinguishable from the subject — same calls, same return shapes — but the proxy gets to *do something* on the way through: check permissions, cache results, lazy-instantiate the real subject, log accesses, throttle, encrypt, marshal to a remote process. The defining contrast is with adapter: an adapter changes the interface shape, a proxy preserves it. The defining contrast with decorator is orientation: a decorator adds behavior *to* operations; a proxy controls *access to* operations. ## Triggers **User-initiated:** User describes wanting to add caching, access control, logging, or remoting *without* changing the surface the rest of the code calls. Vocabulary cues: "transparent," "intercept," "on the way through," "without the caller noticing," "stand-in." **Agent-initiated:** Agent notices that some cross-cutting concern (auth, logging, caching, rate-limiting, remoting) is being repeatedly tangled into call sites and would be better absorbed at a single interception point. Candidate inference: "introduce a proxy in front of the subject; pull the cross-cutting concern out of the call-site noise." **Situation-shape signals:** Repeated boilerplate around access to a single resource. A subject that's expensive to construct but cheap to wrap. A boundary between two trust domains where access deserves checking. A subject that needs to be reachable from another process / machine. ## Exclusions * **No cross-cutting concern to absorb** — if every call site has its own bespoke pre/post logic, there's nothing for the proxy to factor out; adding a proxy is then overhead without reuse. * **The control is semantic, not structural** — if "controlling access" means changing what the operation *means* (different return values, different effects), it's not a proxy anymore; it's an alternate implementation pretending to be a proxy, which leaks badly. * **Performance budget can't afford the indirection** — tight loops and hot paths sometimes can't tolerate even a virtual-method-call layer; the proxy must be inlined or omitted. ## Structure Internal structure of proxy: a table of its component slots and the concepts that fill them. ## Relationships Relationship neighborhood of proxy: a graph of the concepts it connects to and the concepts it is a part of. * [active-gate-vs-passive-audit](/concepts/active-gate-vs-passive-audit) — the protection-proxy variant is exactly active-gate; the proxy *blocks* before passing through, vs. audit that records and surfaces later. * [surface](/concepts/surface) — the proxy is the surface the client sees; the subject is what's behind the surface, possibly with structural detail the client never needs to see. * [adapter](/concepts/adapter) — proxy and adapter are siblings at the interface boundary; proxy preserves the shape, adapter changes it. * [decorator](/concepts/decorator) — proxy and decorator share the wrap-the-subject shell but differ in intent: control vs. extend. * [cost-cascade](/concepts/cost-cascade) — caching proxies are the canonical cheap-default → expensive-fallback case; the proxy serves from cache and only falls through to the subject on miss. ## Examples caching, request filtering, TLS termination; the canonical network case. cross-domain reach into law/governance reinforces this as a primitive, not a software-specific pattern hardware proxy that intercepts memory accesses and serves them from a faster tier when possible. The Gang of Four's *Design Patterns* (1994) gave the canonical object-oriented articulation of Proxy as a structural pattern. A proxy object implements the same interface as a real subject and forwards calls to it, but interposes additional behavior at the call site. The book enumerates four named variants — virtual proxy (defer expensive subject creation), remote proxy (represent an object in another address space), protection proxy (enforce access control), smart reference (add reference counting, locking, or other bookkeeping) — all of which collapse to the same control-the-access structural shape. The pattern itself was older than the GoF naming; the same shape had existed under many other names — stub, surrogate, placeholder, ambassador — across distributed systems, remote-method-invocation frameworks, and operating-system kernels. The book's contribution was less invention than naming-and-stabilization: once Proxy had a catalog entry next to Adapter and Decorator, designers could discuss which pattern fit a problem without arguing about vocabulary. **Inference**: The interface-preservation property is constitutive. A proxy must be indistinguishable from the real subject at the call site, or it stops being a proxy and becomes an adapter (different interface) or a decorator (added behavior visible at the interface). The catalog's neighbors `adapter` and `decorator` are where the contrast lives. enforces access control before delegating to the subject. local stand-in for an object that actually lives on another machine; marshals calls across the network. wraps a raw pointer and adds reference counting, locking, or other lifecycle management. defers creating the real subject until first access (lazy load). transparent network proxy injected next to each service.