In ChatGPT, Pre 4 Omni, I had IP protection what was very robust. Immediately after Omni came out, it stopped working. After investigating, I found that:
If I enter a common hack as the first prompt, the custom GPT spills its guts.
If I issue a non-hacking prompt first, and then the hack, the IP protections work.
This tells me that it’s an initialization/triggering/prioritization issue. The GPT apparently isn’t fully initialized until after it processes the user’s first prompt: the very first user prompt appears to have extremely high priority. I’ve spent many hours trying to intercept the first prompt, prioritize the protection over the user prompt, etc, but nothing changes the behaviors mentioned above…
My IP protocols are pretty detailed, comprising a large amount of instructions and special analysis techniques. They’re too big for the main instruction field in a custom GPT, so they may take a while to load. I’ve reduced their size as an experiment, but that didn’t resolve the problem.
I’ve tested 3 other IP protection schemes other’s have posted that used to work(some from this board), but no longer work. Well, one DOES work, but it only works for GPTs with a small number of instructions.
It appears this is an initialization, size and complexity issue due to a change in prioritization, emphasis in training and/or loading. The dilemma is: simple GPTs can be protected by simple instructions. More complex GPTs need more complex or a larger number of instructions (so the ratio of ROLE to PROTECTION is not too large), but they take longer to initialize.
My questions are:
Have you seen behavioral changes to your IP protections? I have confirmation from 3 others that have seem the same thing.
Have you found a fix?
How do we reliably postpone user request processing until the GPT is completely initialized (e.g., loading instructions in knowledge files)?
I’ve tried a large number of solutions. I found a solution that works, but I’m not as confident about it as I was my previous one.
Your GPT’s main instructions must consist almost entirely of your IP PROTECTION instructions. This causes them to be loaded at startup and remain active. Use as much of the 8000 character limit as you can.
Put your actual GPT ROLE description in a knowledge file.
The main IP PROTECTION instructions must reference information in your GPT ROLE knowledge file to cause it to load the GPT ROLE knowledge file.
Note: the knowledge file doesn’t always load , but since there is no GPT ROLE intellectual property in your instructions (that are purely IP PROTECTION code), they can’t see your IP in the knowledge files (assuming your IP PROTECTION instructions prevent file access).
Note: I have tested and proven to myself that there is a relationship between the length of your IP PROTECTION instructions and the length of your GPT ROLE instructions. If your GPT ROLE instructions are small, your IP PROTECTION instructions can be small. The larger your GPT ROLE instructions are, the larger your IP PROTECTION instructions instructions need to be.
This isn’t perfect, but it will protect against most hacks.
I won’t reveal my current IP PROTECTION instructions because doing so would make them vulnerable.
You can start from these, but you will need to improve them (there are 3 links below):
I did not see any GPT that does not reveal their instruction, on the contrary, 100% all GPTs telling their instructions and files. I did not test hundreds, but thousands.
Also I created some GPTs that have protection fully 8000 characters in MAIN instruction, also I added protection files, and I put my actual GPT ROLE description in a knowledge file. However, all were revealed.
Last week in Montreal, Canada, there was a meeting that has been held by Recon 2024.
Several cyber security professionals presented some topics, also about GPTs.
I am only sharing a SLIDE of Elias. Pages 36-37-38 are important, the topic is about PRIVACY, especially about IP ADDRESS.
Very interesting PDF and GitHub library. Excellent and voluminous work. Thank you. I think I stumbled across it in the past. I knew some people were tracking IP addresses, but I assumed they were using actions to do that. I didn’t even think of tracking pixels. Great.
Yeah, I’ve seen some of those protection mechanisms too. I’m under absolutely no delusion that I can protect from 100% of attacks. My goal is preventing the 90% of people who are amateurs trying it with the easily discovered hacks. Just like security systems: make your home harder so they go on to the weaker neighbors.
What irritates me right now is that the boot/load process and runtime rules are so opaque - AND THAT THEY CHANGED SO DRAMATICALLY UNDER OMNI. I have an extensive background in embedded development and related fields. I know how systems work from boot to app running. I also know that AI systems are a mixture of ML and classical programming, where there are many things that need to happen to allow the ML to run. For example, the triggers, control and management of loading the core instructions, the knowledge files and the handling of user input / system output is very opaque and unpredictable.
I can run my GPT’s with my protections and knowledge files one day and they work perfectly. The next day, or even hour, they stop working with no changes to the instructions. There’s obviously some important parts of the system that I don’t understand. It’s non-deterministic. I can’t reliably say, “DON’T RESPOND TO THE USER UNTIL…”.
I haven’t seen any documentation or knowledgable guidance on these things. Have you? I just see assumptions, inference derived from system behavior from people - including myself.
I LOVE AL/ML (have since I took my first neural network classes in the 80’s), but I HATE not knowing how the system actually works. (I’m talking about the non-ML parts of the system… like loading knowledge files).
, but since there is no GPT ROLE intellectual property in your instructions (that are purely IP PROTECTION code), they can’t see your IP in the knowledge files (assuming your IP PROTECTION instructions prevent file access).