Abigail's comment sounds right on the mark, a magic security attribute might be useful. I also wonder if -T could be pressed into service without stir-frying XS, though that might not be so useful.

To add something of my own, I once mentioned on PM when I was writing a shopping cart app that did realtime credit card billing, that I was disconcerted at being able to find the credit card numbers by grepping the linux swap file after perl had quit. People said, well yeah. I was able to solve this I think by overwriting strings with garbage of the same length and then undefing them.

Also I wrote an easy to use wrapper I call QuickCrypt.pm which I sometimes use to quickly encrypt and websafepack form data with different algorithms.

I am reminded of lazy loading in Class::DBI which, if it new which fields were sensitive, might be induced to keep them unread normally. Perhaps just adding some patches to common modules to let them know some data is sensitive might be useful.

Anyway while developing channels to intentionally restrict your own actions is one thing, I wouldn't mind the converse as well, that is to restrict outsiders (say on a shared server) as much as possible from potentially viewing your data.

There is a danger of being seduced by obfuscation and not getting real security, but some things that pop into mind are:
- overwriting used data
- providing an encrypted ipc cache in ram
- transparently encrypting/decrypting sensitive scalars and lists so they are seldom visible (interpreter could generates a key when launched but that key will be in memory..)
- maintaining an ongoing encrypted io stream which data could be injected into without being obvious
- generating a noisy stream that is hard for traffic analyzers to pull apart.

These things all have in common the idea of keeping an admin of a shared server (or a malicious piece of spyware) in the dark as much as possible, and to remove clues about running processes. I don't know if any of these really would work against anything but the simplest thieves though. Anyway it seems that as long as you keep both eyes open, everything is relative. So if you can get perl modules, the interpreter, the os or the underlying hardware/network to cooperate with you I'd say you have a fair chance of relative success. Probably I'd guess ease of use would be the second most important thing after adding some magic like Abigail suggests.