Skip to content
Riptides Docs

Guardrails for an AI Agent

This example walks through the full agentic workflow end to end. You bring a coding agent under Riptides, watch what it does, then lock it down to just the models and tools it should use, and confirm the guardrails work. The scenario uses a Claude Code agent (claude) that calls the Anthropic API and a Linear MCP connector; the same flow applies to Codex (codex).

Scenario

Section titled “Scenario”
                          ┌──────────────────────────────┐
                          │        Riptides host          │
                          │                               │
     you  ─────────────▶  │   claude  (AI agent)          │
   (drive the agent)      │      │                        │
                          │      ├──▶ Anthropic API (LLM)  │
                          │      └──▶ Linear MCP (tools)   │
                          └──────────────────────────────┘
                                   observed + governed by Riptides

You will:

  1. Confirm the agent is identified and its AI traffic is inspected.
  2. Watch a session in the Activity Monitor.
  3. Restrict the agent to specific models and tools.
  4. (Optional) Scope stricter rules to a specific person.
  5. Verify a blocked attempt and trace it back to the policy.

Prerequisites

Section titled “Prerequisites”
  • A Riptides daemon on the host where the agent runs. See Getting Started.
  • The agent defined as a workload identity with AI traffic inspection turned on. The easiest way is the Identities screen in the console, where TLS intercept is on by default. The key setting is connection.tls.intercept: true, which lets Riptides decrypt and inspect the agent’s HTTP(S) calls. Traffic on the standard HTTP and HTTPS ports is evaluated automatically, so no separate flag is needed. As code it looks like this:
apiVersion: core.riptides.io/v1alpha1
kind: WorkloadIdentity
metadata:
  name: claude
  namespace: riptides-system
spec:
  workloadID: claude
  scope:
    daemonGroup:
      id: daemongroup/dev-eu-west-1/on-demand-workers
  selectors:
    - process:name: claude
  connection:
    tls:
      mode: PERMISSIVE
      intercept: true

With this in place, the agent’s calls to LLMs and MCP servers are observed and governed, with no changes to the agent itself.

Step 1: Watch a session

Section titled “Step 1: Watch a session”

Run the agent as you normally would, then open Agentic → Activity Monitor. Your run appears as a session. Open it and view the graph: you will see yourself as the caller, the claude agent, the models it used, and, if it called Linear, the list_teams or search_issues tools with the Linear service behind them.

This is your baseline. It shows exactly which models and tools the agent actually uses, which is what you will allow in the policy.

Step 2: Decide the guardrails

Section titled “Step 2: Decide the guardrails”

Suppose you want the agent, when running unattended, to:

  • use only the Claude Haiku model on Anthropic (not the larger, more expensive models), and
  • use only read-style Linear tools (search_issues, list_teams), never anything that creates or changes data.

You do that by adding Anthropic and Linear to the Autonomous Operation policy and narrowing each. Other providers or connectors you never add stay unrestricted for that policy scope.

Step 3: Create and narrow the policy

Section titled “Step 3: Create and narrow the policy”
  1. Open Agentic → Access Control and choose Add policy.
  2. Select the claude workload identity and confirm. This creates an empty policy (full access) which you now narrow.
  3. In the editor, select Autonomous Operation (the rules for the agent itself).
  4. On the LLM Models tab, Add restriction for the Anthropic provider, expand it, and leave only Claude Haiku toggled on.
  5. On the Connectors tab, Add restriction for the Linear connector, expand it, and leave only search_issues and list_teams toggled on.
  6. Choose Save.

The dashboard now shows claude with its LLM and Connector counts and an Autonomous: Restricted badge.

The same result as YAML:

apiVersion: core.riptides.io/v1alpha1
kind: TrafficPolicy
metadata:
  name: claude-autonomous
  namespace: riptides-system
spec:
  workloadID: claude
  llmRules:
    - llmRef:
        name: anthropic-api
      models:
        - claude-haiku-4-5-20251001
  connectorRules:
    - serverRef:
        name: mcp-linear
      tools:
        - search_issues
        - list_teams

Step 4 (optional): Scope stricter rules to a person

Section titled “Step 4 (optional): Scope stricter rules to a person”

If you want different limits depending on who is driving the agent, add a user policy. In the editor choose Restrict user, pick the person from your Users, and set their restrictions. Their rules apply only when they drive the agent. Autonomous runs still use only the Autonomous Operation policy from Step 3. Other users who do not have their own policy are not covered by Autonomous Operation; they keep full access until you add a user policy for them.

Step 5: Verify the guardrails

Section titled “Step 5: Verify the guardrails”

Run the agent again in a context the policy covers, for example unattended after Step 3, or as the restricted user after Step 4, and have it try something outside a restriction, such as a larger Anthropic model or creating a Linear issue. In the Activity Monitor:

  • the Blocked events card goes up,
  • the session is flagged, and
  • the blocked model or tool node is tagged red in the graph.

Note the workload and who was driving, then open Access Control for that agent and select the matching Autonomous Operation or user policy to confirm or adjust the restriction.

Security highlights

Section titled “Security highlights”
  • No changes to the agent: guardrails are applied to the agent’s traffic, not baked into its configuration or code.
  • Default allow, restrict by rule: traffic is allowed unless you add a restriction for that provider or connector; then only the models and tools you leave on for that service are permitted.
  • Autonomous vs. human-driven: Autonomous Operation and per-user policies are separate, with no fallback between them, so you must set each scope you care about.
  • Observable enforcement: every block is visible in the Activity Monitor, so you can audit what was denied and reconcile it with the policy in Access Control.

Next steps

Section titled “Next steps”