Your pricing engine loads another team's plugin into its own process - where does the trust boundary go, and can one exist inside a process?

## Trust can change with no network and no login Most people learn boundary placement on diagrams where the boundary happens to coincide with something visible - a client talking to a server, a service talking to a database. The harder and more interesting cases are the ones inside a single machine, where the trust change comes from **who wrote the code** and **what it executes as** rather than from where the packets go. Take a pricing engine in a monorepo that loads another team's plugin into its own process at startup: a pluggable strategy that computes an adjustment. There is no hop, no authentication event, no tenant switch. Yet the trust level plainly changes at the call into that plugin: you did not write it, you do not review every change to it, and its authors' compromise - a bad merge, a compromised developer account, an upstream dependency pulled into their module - becomes your compromise. ## What is actually at stake Name the adversary and asset before arguing about the line. Here the adversary is a compromised upstream team or a dependency inside their module, and the assets are the trade-secret pricing model and the engine's continued operation. In-process, foreign code gets: - **The whole address space** - your model coefficients, cached inputs, and anything else in memory, which is IP disclosure without a single outbound flow appearing on your diagram. - **Your process identity and credentials** - every secret the engine holds, every downstream system it may call, and its ability to write wherever it may write. - **Availability** - an uncaught exception, an infinite loop, an allocation storm, or a call to exit takes the engine down with it. So the crossing is real, and if you did not draw it none of those threats appear in the enumeration. ## The awkward truth: a boundary you cannot enforce A trust boundary is a *claim about trust*, but a boundary is only a *control* when something at the crossing enforces it. Inside one process nothing does - same address space, same principal, same rights. A language-level module system, a plugin interface, or an internal API surface is an engineering convention, not a security control against code running beside it. That leaves you two honest options, and the senior answer is knowing which you are choosing: 1. **Draw the boundary and label it unenforced.** The line still earns its place: it forces the threats above onto the list and makes the assumption explicit - "we accept the plugin's authors as fully privileged inside this process, controls are code review and the ownership contract". Now it is a stated risk somebody can accept or reject, not an invisible one. 2. **Change the design so the line can be enforced.** Move the foreign code out of the process. ## When the process change *is* the boundary Option two is the reason execution context appears in the list of trust-change triggers. Consider a different shape: a media-transcoding worker that shells out to a third-party codec binary as a child process to handle uploaded files. The adversary is a compromised dependency arriving as a malicious input file, and the asset is availability of the transcode fleet. Here the process split does the work: - The child has its own address space, so a memory-corruption bug in the codec does not immediately hand over the worker's credentials. - The child can run as a **different OS user** with no access to the worker's secrets, a read-only view of the input, a scratch directory for output, and no network. - It can be capped - CPU time, memory, wall-clock - so a decompression bomb costs one job rather than the fleet. - The result channel is narrow and typed: a file plus an exit status, both validated by the parent before use. That is an enforced boundary, and it is enforced by the operating system rather than by discipline. The caveat matters as much as the pattern: **a child process is not automatically a sandbox**. Fork a child as the same user, with the same environment, the same file descriptors and the same network access, and you have moved code without moving privilege. The boundary exists when the privilege on the far side is genuinely smaller and the inputs and outputs crossing it are constrained. ## How to reason about it in an interview Work the derivation out loud in this order: *what changes here* (code ownership, then execution context), *what does the far side get* (memory, identity, availability), *what enforces the line* (nothing in-process; the OS once split), *what do I write on the diagram* (boundary with an unenforced annotation, or a real one after the design change). A candidate who states that a boundary with no enforcement is a finding rather than a control - and who does not pretend a module interface is a security perimeter - is demonstrating exactly the judgment the question is asked for.