Skip to content
Riptides Docs

Agentic AI Overview

Riptides secures and observes the AI agents running across your fleet. It shows you every model an agent talks to, every tool it invokes, and the person driving it, and it lets you set guardrails on which models and tools each agent is allowed to use, all with no changes to the agent or its configuration.

AI agents are a new kind of workload: they act semi-autonomously, reach out to external LLM providers, and increasingly call real systems through tools (creating issues, querying databases, sending messages). That makes two questions urgent. What are my agents actually doing, and how do I keep them inside the lines? The Agentic AI features answer both.

What you can do

Section titled “What you can do”

The Agentic section of the console groups everything AI-related:

  • Activity Monitor: see every AI session as a graph: who ran the agent, which models it used, which tools it called, and anything that policy blocked.
  • LLMs: the model providers your agents can reach (Anthropic, OpenAI, Mistral, and others), and the models each one offers.
  • Connectors: the MCP servers registered in your system (Linear, GitHub, Slack, and more) and the tools they expose.
  • Users: the people who drive agents, so a policy can be scoped to a specific person.
  • Access Control: the policies that decide which models and tools each agent may use, and who is allowed to drive it.

Key concepts

Section titled “Key concepts”
  • Agent: in agentic AI terms, an application that uses a large language model to pursue goals and take actions, typically with some autonomy, often by calling tools or external systems, not only by answering a single prompt. In Riptides, each agent is represented as a workload identity whose AI traffic is observed and governed. (See Current limitations at the end of this page for what is written and tested today.)
  • Session: one agent run for a given workload and person. A session groups the back-and-forth exchanges the agent has with an LLM, including the tool calls it makes along the way.
  • Exchange: a single request/response turn with an LLM: the input, the model’s response, any tool calls it emitted, and token usage.
  • LLM: a model provider Riptides recognizes as an AI service (for example anthropic-api). Each provider exposes a set of models.
  • Connector: a registered MCP (Model Context Protocol) server, such as a Linear or GitHub integration. Each connector exposes a set of tools the agent can call.
  • Tool call: an agent’s invocation of a tool. This can be a local (built-in) tool the agent runs itself, such as reading a file or running a command, or a tool exposed by an MCP connector (for example create_issue) that is routed through the MCP server behind it. Both kinds show up in the Activity Monitor; only connector tools have a service behind them.
  • User (actor): a person from the Users directory (from an identity provider or added manually). A policy can be scoped to a specific user so its rules apply only when that person is driving the agent.
  • Access policy: restrictions on models and tools for one agent, optionally scoped to one user (or to autonomous runs with no user). Default is allow; only providers and connectors you add a rule for are restricted.

How it works

Section titled “How it works”

Riptides runs on each host and gives every workload a cryptographic identity. When an AI agent calls an LLM or an MCP server, Riptides recognizes the call as AI traffic, applies the matching access policy when one governs that agent and driver (blocking models or tools that policy does not allow for that service), and records the interaction so it appears in the Activity Monitor. This happens transparently: the agent makes ordinary API calls, and Riptides observes and enforces in the middle, with no SDK, proxy configuration, or code changes in the agent.

Because enforcement and observation are built on the same identity and connection security as the rest of Riptides, an agent is governed the moment it has an identity, and there is nothing to install into the agent itself. Policies are scoped: Autonomous Operation covers unattended runs, and each user policy covers only that person. A human without a user policy is not limited by Autonomous Operation. For each policy, traffic is allowed by default and only the providers and connectors you restrict are narrowed. For the underlying platform, see Platform Architecture and Connection Security.

Next steps

Section titled “Next steps”