Hi Quinn, thank you for asking — I should have made the process roles clearer. The child is one of the test processes, but the credential restriction is not limited to it: A: the sandboxed parent/driver application. B: A’s child, inheriting its sandbox and an existing socket descriptor. C: the separately signed, sandboxed receiver application communicating with A through the App Group UNIX-domain socket. O: a separate observer collecting bounded test evidence, which also needs its permitted resource access defined. The credential restriction needs to cover all four roles, using controls appropriate to each role’s execution context. I am not assuming that B inherits A’s Keychain access-group membership merely because it inherits A’s sandbox. This is a controlled synthetic test harness whose code we own. The requirement concerns OS-enforced prevention of credential retrieval, use, modification, and out-of-scope creation — including otherwise accessible own-group Data Protection Keychain items and file-based keychains. It is not a blanket prohibition on harmless Security.framework operations, such as public-certificate or trust lookups. Does a supported execution context or isolation arrangement provide that restriction while preserving the parent–child relationship and local IPC described above?