Where should guardrails sit: gateway, sidecar, or application?

All three, with different jobs. The gateway enforces the organization-wide baseline that no team can disable. The application enforces context-specific rules that require knowledge only it has. The sidecar handles per-service policy where you need enforcement close to the workload without modifying its code. The mistake is picking one and expecting it to cover the others.

The gateway is where you put universal controls: personal data redaction, prohibited topic denial, model allowlisting, rate and cost limits, and logging. It is cheap to operate, applies uniformly, and cannot be bypassed by a team shipping fast. It also has no idea what your application is doing, so it cannot distinguish a support agent asking about a customer record from an exfiltration attempt phrased identically.

The application layer has that context. It knows which user is authenticated, what they are entitled to see, and whether the requested action is in scope for this session. It is also the hardest layer to govern centrally, because enforcement lives in code owned by whoever wrote it.

The sidecar is the compromise for service meshes and multi-tenant environments, giving per-service policy without embedding it in application code.

For agents, the placement question has a specific answer that overrides the general one: enforcement must reach the tool-call boundary. A gateway sitting between your application and the model provider never sees the agent invoke a tool, because that call does not traverse it.

Akto Argus enforces at that boundary with a runtime guardrail policy plane that spans runtimes rather than binding to one gateway or one cloud.

Baseline at the gateway. Authorize at the tool call. Everything else is optimization.