They are very very similar to regular key objects and act as an override for those keys. What happens here is:A developer requests a keyThis creates a key request (a key request is generated from the information in the portal catalogue entry, it basically combines some metadata and a policy ID)The key request combines the developer ID and the policy ID they want access toIf approved, Tyk will generate a token with the policy values, AND link the policy to the token. It then puts the key record alongside the developer so that now the token has some kind of organisational and developer identity metadata.Policies override the core token values when the key shows up in the traffic flow, so if you update a policy, ALL keys that are attached to it will adopt those new settings instantly, it's a good way to manage swathes of keys and create tiered access (e.g. trial, pro, enterprise access etc.)Policies don't overwrite existing quota usage (so if a key has used 100 out of 110 requests, that 100 usage will still count, if you lower the policy value or increase it, the maimums will change, so it's safe to change them.

If you make a policy inactive it no longer will be loaded by the Tyk cluster (they are held in memory to avoid having to call back to the DB)

If you wish to stop access to all keys using a policy (e.g. if you have company- or client- based policies) then if you set the deny_access parameter on the policy, all tokens that use that key will top having access to your systems and be blocked, great if they have an outstanding bill