This is a promising but premature approach.
The 370 space bank went thru some philosophy shifts during its development and has some features that I cannot now justify. To fix the covert channel problem I think that it is best to devise a new state for the bank of holding a reserved pool of nodes that it is able to allocate from. The current bank conceptually goes to the top of the hierarchy for each allocation, depleting limits all the way up, just like the meter logic. In the modified design the allocation would go up only to a bank with a reserved pool depleting limits only to that point. Now real space would be reserved for the confined object.

In some applications it is too difficult or too expensive to reserve the right amount. It would be to call a bank keeper when the pool was exhausted. This particular keeper would have the job of monitoring the signals that emerged from the confined object and modulate, limit and obfuscate them. In particular it could report on the amount of information that escaped as it allocated temporary storage from unreserved resources.

Here is a scenario we must consider: Program X within a confined realm invokes a factory, passing a bank that is insufficient to create the required domain. The factory serves unconfined clients as well and must not be stalled while a covert channel limiter contemplates the situation. This would happen if the keeper of the bank were invoked to arrange for additional storage and that keeper stalled to muffle wall banging.

With the factory and bank logic of the 370 system, the factory requires a prompt bank, and that bank denies the space request instead of stalling. This covert channel is thus checked but the confined application is likely broken when it wasn’t really its fault.

We could require a distinct factory within the realm but I really don’t like that for then the factory builder would have to consider whether a particular factory required this extra expense. As it is now factories just naturally produce discreet yields at no extra cost.

One unpromising solution observes that the continuation for the invocation of the factory’s requestor key must be a resume key. Imagine another primitive capability that would “back up” the domain referred to by some proferred resume key. The factory upon rejection would back up its requestor and send a message to the bank to wake up this guy when space was available. This is sort of like what the kernel does when it must stall a domain for I/O while it serves other domains. Ugly! Perhaps the new primitive would consume the resume key and produce a restart key. I think that this might avoid introducing more domain states. After this substitution the domain would be waiting but the situation would be as if a meter trap had occurred. The new primitive would not operate on a restart key. This would avoid the issue of multiple backup operations. Perhaps the distinction between resume and restart keys could originally better have been addressed in additional domain state instead of key type variety.

This needs to be coordinated with unprompt bank design.
Here is an incomplete bank design for this problem.