A custom GIS plugin repeatedly corrupts neighboring processes by writing into their memory spaces. Which operating-system capability should architects insist on to contain that class of failure?

A custom GIS plugin that corrupts neighboring processes by writing into their memory spaces is exploiting—or bypassing—process isolation. Architects should insist on operating-system memory protection that isolates process address spaces and blocks unauthorized cross-process writes, so a faulty or malicious plugin cannot freely mutate another process’s memory. Complementary controls (ASLR, DEP/NX, sandboxing) strengthen that isolation story. Running every desktop app as the same shared Local System account collapses identity isolation and often weakens the practical value of process boundaries for lateral impact. Turning off ASLR and DEP to simplify vendor stack traces deliberately disables memory-safety mitigations that limit exploitation of exactly these classes of bugs. Mapping all plugins into one global writable memory region for performance recreates the failure mode as an architectural feature. Exam caveat: memory protection / process isolation is a fundamental OS security capability on the exam; performance and debugging convenience do not justify disabling it in production civic systems. Operational check: verify the GIS host runs plugins out-of-process or in sandboxed processes where possible, keep ASLR/DEP enabled, avoid shared System accounts for user apps, and retest the corrupting plugin under isolation to confirm cross-process writes are denied and faults stay contained.