Depending on the sensitivity of the data, I would suggesting the following items, arranged from least secure to most secure.
Do Nothing: Based on the contents of your question, I'd probably choose this option. A lookup filter isn't associated to a user (apparently) and probably doesn't expose anything particularly interesting. You could even expose the PK directly without too much worry, unless those filters could expose sensitive data. I know plenty of systems that use other means of protecting filters (and all other data), most notably using an actual session ID so the filter can only be seen by users authorized to see it.
Randomize PK: Make the PK a random number instead of auto-number. This keeps people from guessing PKs by counting back and forth. This makes it harder to find a valid filter. I would use this if the filter doesn't contain any sensitive data at all; make it non-trivial for an attacker to find a random filter. I would use a large random number space, such as 64-, 128-, or 256-bit numbers. Use this if you simply want to avoid people "sniffing" your database for interesting values.
Sign PK: Attach a nonce or MAC to each PK, so that the nonce and PK together are needed to retrieve the value. This prevents casual modification of the PK on the client. Validate that the MAC or nonce matches the expected value. This should deter casual hackers, especially if the data is particularly uninteresting and doesn't contain personal information.
Encrypt PK: Simply encrypt the cookie before sending it. This is the first recommendation in the list that suggests that the PK isn't directly sent to the client, and I would only use this method for personally identifying information, or if exposure of the filter would result in potential fraud. I would also combine this step with signing and randomization for a robust solution.