If you integrated an existing AI Gateway, such as LiteLLM, with Cato, the configuration model has changed. AI Gateway configuration now lives in Guards, so Guards are the single place where you generate the authorization key and map virtual keys for AI Security for Applications.
Your existing configuration was migrated automatically. Your authorization keys remain unchanged, and existing AI Gateway integrations continue to work without changes. In addition, the Guards policy and your rules continue to work as before.
Quick Summary
Previously, connecting an existing AI Gateway to Cato required two separate object types:
- You configured the AI Gateway in the CMA to generate the authorization key.
- You created one or more Guards, with one Guard for each virtual key in the gateway.
These objects are now consolidated. You create a single Guard for each AI Gateway. The Guard generates the authorization key and contains the virtual key mappings. Each virtual key is represented as a Homegrown Agent, visible on the Homegrown Agents page.
Before and After
Before
To protect traffic coming from an AI Gateway, you created an object representing your AI Gateway in the CMA to generate the authorization key. Then, you created a separate Guard for each virtual key in that gateway.
After
You now create a single Guard for the AI Gateway. The Guard generates the authorization key and contains all virtual key mappings. Each virtual key represents a Homegrown Agent.
Where to Find Things
| What You're Looking For | Where It Is Now |
|---|---|
| Your AI Gateways | Guards page — single Guard per AI Gateway |
| The Guards you created for each virtual key | Inside the single Guard configuration for the gateway |
What's New and Why Cato Changed It
Guards are now the single place where you integrate agents with Cato and generate an authentication token for Cato AI Security for Applications. Whether you are integrating a single agent or multiple agents behind an AI Gateway, the configuration is managed from Guards.
This change also adds more granular policy scoping. Previously, you could apply rules only at the virtual key (agent) level. Now that a single Guard can map multiple virtual keys, you can apply policy at two levels:
- Gateway level: Apply rules to the Guard that represents the AI Gateway. These rules apply to every agent behind it.
- Agent level: Apply rules to a specific Homegrown Agent. These rules apply only to traffic from that virtual key.
This lets you use a single Guard to manage traffic from multiple teams or use cases while applying different policies to each agent when needed.
Frequently Asked Questions
Do I Need to Update My Gateway Configuration?
No. Your authorization key has not changed. Any existing gateway configuration that points to a Cato authorization key continues to work without modification.
Where Did My Old Guards Go?
Guards that were previously associated with AI Gateways were migrated and are now visible on the Guards page. Their virtual key mappings are preconfigured inside the Guard.
What Is a Homegrown Agent?
Each virtual key in your gateway configuration now corresponds to a Homegrown Agent in Cato. Homegrown Agents let you view traffic, configure per-agent policy, and report on usage at the virtual key level.