One integration is granted an exception to open inward from the exchange tier — how do you constrain it against an intruder who owns that host, and what does keeping it cost?

## Why the exception exists at all The exchange tier's defining rule is that it never initiates inward, and almost every integration can be inverted into an interior-initiated pull. The one that cannot is usually synchronous: a partner submits an order through the portal and the answer depends on live interior state — stock, credit, entitlement — inside the partner's request. A collection interval cannot produce that answer; someone has to ask, now, from the tier. That is a legitimate business requirement and pretending otherwise gets the exception granted anyway, informally, by someone with less care. The engineering job is to make it the narrowest thing that satisfies the requirement. ## Narrowing it, layer by layer **The permit.** One source address, one destination address, one destination port. Not the tier subnet, not the application server group, not a range. The moment the permit names a group, it grows silently as hosts are added to that group by people who have never heard of this rule. **The endpoint.** The exception must not land on the system of record. It lands on a purpose-built receiver whose entire vocabulary is the one question that needed asking: *is this credit line available for this partner account?* — not a query interface, not a general API gateway to the interior estate, and never a database listener. If the receiver can express only one question, a stolen path can ask only that question. **The identity.** The path is authorised at the network layer; the *interaction* must be authorised at the application layer, with mutual authentication and a service identity that belongs to this integration and nothing else. Assume the credential material on the tier host is already in the intruder's hands — it sits on a box in the untrusted zone — and design so that possessing it grants exactly the one operation, on the one account scope, that the business case named. **The direction of the answer.** Prefer a request that returns a decision rather than one that returns data. "Approved / declined" leaks far less than a customer record, and a stolen path that returns booleans is a poor exfiltration channel. **The blast radius on the interior side.** The receiver validates input against a fixed schema, refuses anything else, and never lets a value in the message become a path, a query fragment, or a destination. Bound what a single call can affect, and make the operation idempotent so a replayed call is not a second effect. ## What the intruder can still do, even done well This is the part that separates a designed exception from a hopeful one. With everything above in place, an intruder who owns the tier host still *is* the sanctioned client. They can: - Call the sanctioned operation, with valid authentication, containing false content — an order for an account that never placed one, a lookup on an account they are curious about. - Enumerate through the parameter the operation accepts, learning the interior's answer for many inputs. - Observe every legitimate request and response passing through the tier. So the exception is never "safe"; it is *bounded*. The bound is the receiver's vocabulary, the identity's scope, and what a single answer reveals. If the honest analysis is that the operation would let an intruder read the customer base one query at a time, then the operation is the wrong shape and needs redesigning — a scoped decision rather than a lookup, or a pre-pushed replica in the tier holding only the subset the portal may see. ## The cost of keeping it An exception is not a one-off decision; it is a standing liability with a maintenance schedule: - **A named owner and a stated reason.** "Historical" is not a reason. If nobody will put their name on it, it is a candidate for deletion, which is the cheapest outcome available. - **A renewal date.** The business case that justified it — a partner contract, a synchronous SLA — can end without anyone telling the network team. A renewal forces the question. - **Evidence.** At each review you must be able to show that this is still the *only* inward-initiated permit, and that the boundary denies everything else. That means testing from the untrusted side on a schedule, not reading the rule base, because rule bases acquire lines that nobody remembers approving. - **Precedent management.** The strongest argument for the second exception is the existence of the first, and the tenth arrives by the same reasoning. The countable, defensible position is a stated ceiling: this tier holds one inward exception, and a new one displaces it or is refused. ## How to answer in a loop The weak answer is "we lock it down to a specific IP and port". The strong answer walks the layers — permit, endpoint, identity, response shape — names what remains possible for an intruder who owns the host anyway, and then says what the exception costs to keep and who signs for it. Interviewers are listening for whether you can hold two ideas at once: this exception is necessary, and it is the single most likely path by which the tier reaches the interior.