Are memory safety and maximized data volatility mutually exclusive?

Working on software that handles sparse capabilities, I keep running 
into the issue that the desire to write maximally robust code and the 
desire to maximize the volatility of sensitive data seem to be mutually 
exclusive to the extreme. In C or C++ I don't have memory safety, yet 
the lack of memory safety gives me the power to overwrite sensitive data 
at the moment that the sensitive data is no longer functionally 
required. That means if I make a memory dump of the process a fraction 
of a second later, there is no trace of the sparse caps left.
Doing the same with Python, the results differ and sometimes a sparse 
cap could linger in process memory hours after outliving its functional 
need from the programs perspective. While I haven't ported anything to 
for example Java or Javascript, I imagine given the apparent 
similarities in the design of such runtimes, the results would likely be 
similar for those languages. In fact, I would expect these languages to 
be worse given Python's reference counting based GC and that was the 
main reason I picked Python as first language to port to.

I dislike the idea of memory insecurity. But I dislike the idea of 
powerful tokens of authority lingering in process memory for hours or 
more even more. So if I'dd need to choose at the moment it would be 
hard, but I guess I'dd go with the maximum volatility at the price of 
memory insecurity. I'dd still would rather have seen I didn't have to 
choose between two evils though. But for all practical purposes, the two 
desired properties seem to be mutually exclusive.

Would these all be valid assertions? Or am I jumping to conclusions 
here? And if it is a valid assertion, are memory safety and sensitive 
data volatility mutually exclusive in a "fundamental" way? Or would it 
for example be possible to create a memory safe or even capability 
secure programming language that supports sensitive-data volatility?


Rob