I don't think it's possible to solve this. Either you have a system with perfect security, and that requires immutable authority, or you have a system that is adaptable, and then you risk it will succumb to a fatal flaw due to maladaptation.
(This is not really that new, see Dr. Strangelove, or cybernetics idea that no system can perfectly control itself.)
Yes, that’s true - the current notion of instructions and data are too intertwined to allow a pure data construct.
I can imagine an API-level option for either a data message, or a data content block within an image (similarly to how images are sent). From the models perspective, probably input with specific delimiters, and then training to utterly ignore all instructions within that.
It’s an interesting idea, I wonder how effective it would be.
Platform: Model Spec "platform" sections and system messages
Developer: Model Spec "developer" sections and developer messages
User: Model Spec "user" sections and user messages
Guideline: Model Spec "guideline" sections
No Authority: assistant and tool messages; quoted/untrusted text and multimodal data in other messages
1. A robot may not injure a human being or, through inaction, allow a human being to come to harm.
… etc…
You need something like a calculus of morality and ethics - this is incredibly uncomfortable for people, because it will mean the invalidation of moral relativity and all sorts of arbitrary dogmatic and ideological tradition, and demonstrate a rational basis for intersubjective interaction. ( Take your is/ought distinction and bury it with Hume.)
We need progress, and the sooner we start, the less damage will be done by unaligned systems.
1) system, messages from the model creator that must always be obeyed 2) dev, messages from programmers that must be obeyed unless the conflict with #1 3) user, messages from users that are only to be obeyed if they don’t contradict #1 or #2
Then, the model is trained heavily on adversarial scenarios with conflicting instructions, such that it is intended to develop a resistance to this sort of thing as long as your developer message is thorough enough.
This is a start, but it’s certainly not deterministic or reliable enough for something with a serious security risk.
The biggest problems being that even with training, I’d expect dev messages to be disobeyed some fraction of the time. And it requires an ironclad dev message in the first place.