Skip to content
Riptides Docs

AI Agent Governance

An AI agent is a workload like any other: a process with a workload identity, secured the same way as a service or a CI job. What’s different is what it does with that identity. A service calls a fixed set of destinations in a predictable order; an agent decides at runtime what to call based on an LLM’s output, so the same agent can take a different path through your infrastructure on every run. Identity and network policy alone answer “is this workload allowed to reach this destination,” but they don’t answer the questions that actually matter for an agent: which model did it use, which tool did it call, and who was driving it when it did.

Riptides extends the same kernel-level enforcement it uses for mTLS and credential injection to answer those questions, without adding an SDK, a proxy, or any change to the agent’s code or configuration.

The Building Blocks

Section titled “The Building Blocks”
  • Agent: not a new resource type. An agent is a WorkloadIdentity like any other, with TLS interception turned on so the kernel can inspect its HTTP traffic to recognize LLM and MCP calls.
  • Actor: the human on whose behalf the agent is acting. Riptides resolves this from the credentials the agent itself presents to the LLM provider, so every action carries two identities: the agent’s workload identity and the actor’s. This composite identity is what lets a policy apply only when a specific person is driving, and what lets an audit trail answer “who” as well as “what.”
  • Session and exchange: a session is one agent run; an exchange is one request/response turn within it, including any tool calls the agent made along the way. Sessions and exchanges are how agent activity is organized for observability.
  • Tool call: an agent invoking a tool, which is either local (a built-in action the agent runs itself, such as reading a file or running a command) or routed through an MCP connector. Both are observed the same way
  • LLMs and connectors: the vocabulary a policy is written against. An LLM is a model provider (Anthropic, OpenAI, and others) and the models it offers; a connector is an MCP server (Linear, GitHub, Slack, and others) and the tools it exposes.
  • Access policy: the rule set that governs one agent, applied either to its autonomous runs or to a specific actor driving it.

How It Works

Section titled “How It Works”

Because an agent’s traffic is ordinary HTTPS, Riptides recognizes it the same way it recognizes any traffic it intercepts: by inspecting the connection at the kernel, not by requiring the agent to route through a separate proxy or gateway. Known LLM and MCP endpoints are classified as AI traffic; the driving actor is resolved from the agent’s own provider credentials; and the applicable access policy, if any, is evaluated before the request leaves the host. A call that policy doesn’t allow is blocked at that point, not after it reaches the provider. Every exchange, including anything blocked, is recorded for the Activity Monitor.

Default Allow, Restrict by Exception

Section titled “Default Allow, Restrict by Exception”

An agent with no policy, or an empty one, has full access. Adding a rule for a specific provider or connector narrows only that one: the models or tools you leave on for it are permitted, everything else on that same provider or connector is blocked, and every other provider or connector the policy doesn’t mention stays fully allowed. This means adopting governance is incremental: you can restrict one high-risk connector today without having to enumerate everything else an agent is allowed to touch.

Policy also distinguishes who is driving the agent. An autonomous-operation policy governs unattended runs; a per-user policy governs one specific person driving the agent. There’s no fallback between them: a human with no policy of their own gets full access even if the agent’s autonomous policy is locked down. This lets you, for example, run an agent unattended under a strict allowlist while giving a trusted engineer broader access when they’re the one behind the wheel.

Why Not a Gateway or Prompt Guardrails

Section titled “Why Not a Gateway or Prompt Guardrails”

AI and MCP Gateways

Section titled “AI and MCP Gateways”

A gateway, whether it fronts LLM calls or MCP tool calls, only governs what’s actually routed through it. An agent that makes a direct connection, or reaches anything outside the gateway’s configured path, bypasses it entirely, so coverage depends on every agent being correctly wired to the gateway rather than on anything the platform itself guarantees. Local tool calls make this worse than a bypass risk: reading a file or running a command never goes over the network at all, so no gateway, however well every agent is configured, could ever see it. A gateway is also a piece of infrastructure you now have to scale and keep available: it sits in the request path of every governed call, so its capacity has to grow with your agent traffic instead of with your actual node count.

Riptides enforces where the agent already runs, at the kernel, so there’s nothing centralized to add capacity to, and local tool calls are covered the same way connector calls are. Because every connection is inspected there regardless of destination, you get a complete audit trail of every LLM call, MCP call, and local tool call an agent made, not just the ones that happened to be routed through a gateway.

Prompt Guardrails

Section titled “Prompt Guardrails”

Prompt guardrails try to stop an agent from being told to do something unsafe, but they operate on the prompt, not the connection. A credential sitting in the agent’s memory, or a tool call to an unapproved endpoint, doesn’t have to go through a prompt to happen, so it’s outside what a guardrail can see or stop.

Because Riptides enforces at the node, every outbound connection the agent makes is covered, regardless of which framework, library, or tool call initiated it, and regardless of what the agent’s own reasoning decided to do.

Next Steps

Section titled “Next Steps”