Compare
Portkey vs Guard
Portkey keeps your models running. Guard proves your AI use is compliant. They solve different problems.
Why this comes up
Portkey and Guard both sit in front of your AI calls, so they can look similar on an architecture diagram. The resemblance ends there. Portkey is an AI gateway: it routes requests across providers, fails over when a model is down, caches responses, retries on errors, and tracks spend. Its job is reliability and cost control.
Guard is compliance middleware. It reads every request and response for Australian PII, checks for prompt injection, and signs a per-call attestation mapped to APRA CPS 234, the Privacy Act, and ADM transparency obligations. Its job is regulatory evidence.
If a regulator or your board asks "can you prove your AI controls were active on this specific call," a gateway’s metrics dashboard doesn’t answer the question. A signed attestation does.
Side by side
| Capability | Portkey | 40° South Guard |
|---|---|---|
| Routing, fallbacks and retries across providers | ✓ | ✗ |
| Cost and latency tracking | ✓ | ~ |
| Australian PII detection (TFN, Medicare, ABN) with checksums | ✗ | ✓ |
| Prompt injection detection inside uploaded documents | ✗ | ✓ |
| Per-call cryptographically signed attestation | ✗ | ✓ |
| CPS 234 / Privacy Act regulatory mapping | ✗ | ✓ |
| 7-year tamper-evident audit trail | ✗ | ✓ |
| Australian data residency guarantee | ~ | ✓ |
✓ = supported · ~ = partial · ✗ = not supported
Download the full comparison (PDF)Could you run them together?
Yes, and it’s a sensible setup. Point your application at Portkey for routing and resilience, and run Guard in the same path so every call still produces compliance evidence. You get Portkey’s availability and Guard’s proof.
See Guard on your own AI calls
Book a demo and we’ll show you a signed attestation for a real call — mapped to your obligations under CPS 234, the Privacy Act, and ADM transparency.