Policy Management

Truvant's policy engine controls what commands AI agents can execute and which MCP tool calls they can make — at the subcommand level. Policies apply only to AI agents; human commands pass through unaffected.

Why this matters (LLM06:2025) OWASP LLM06:2025 identifies Excessive Agency as a critical risk when AI agents are granted capabilities beyond what's needed. Policy roles let you define exactly which commands and tool calls each agent is allowed to execute. The Policy Advisor automates this by analyzing actual agent behavior and recommending least-privilege rules — so you can move from broad permissions to tight, evidence-based access without guessing.

Policy Roles

A policy role is a named enforcement profile that defines what AI agents are and are not permitted to do on any host it is assigned to. Roles are managed centrally in the dashboard and sync automatically to all assigned hosts.

The Policy Roles page lists every role in your organization. Assign roles to hosts from the Host Detail view or in bulk from the Hosts list.

Column Description
Name Human-readable role name. Displayed on the Hosts list and in the audit log for every policy decision.
Description Optional free-text description. Useful for documenting the intended use case (e.g., "Production engineer — read-only infra commands").
Hosts Number of hosts currently assigned to this role. Click to jump to the filtered Hosts list.
Mode Monitoring — Observe and log policy violations without blocking them. Use this when building or refining a role.
Enforcing — Block commands and tool calls that violate the role's rules. Use this once you are confident the rules are correct.
Status Active roles are in use. Draft roles are not yet assigned to any host.

Actions per role:

Policy roles list showing enforcement profiles with name, host count, mode, and status columns
Policy roles — manage enforcement profiles for your fleet

Role Detail — Command-Level Rules

Opening a policy role shows its full rule set. Rules operate at the binary and subcommand level — you can allow git broadly while blocking specific dangerous subcommands like git push --force. Truvant matches against the full argument vector of every command the agent attempts to execute.

Example Rules

Command Pattern Action Rationale
git git * allow General git operations are expected for a developer agent.
git push --force git push --force* deny Force pushes can destroy history and bypass code review.
kubectl exec kubectl exec * deny Direct pod execution bypasses cluster access controls.
ssh ssh * deny Agent should not open interactive sessions on remote machines.
terraform apply terraform apply* deny Infrastructure changes require human review; agent may plan but not apply.
aws aws * allow Read-only AWS CLI calls are acceptable for this role.

The role detail view contains four sections:

Role detail view showing command rules table with subcommand patterns, allow/deny actions, and mode toggle
Role detail — command-level rules with subcommand granularity
Recommended workflow for a new role Start in Monitor mode to observe what commands your AI agents actually run. Use the audit log and Policy Advisor to understand the full pattern of agent behavior over several days. Review the generated suggestions, adjust as needed, then switch to Enforce once you are confident the rules cover legitimate usage without blocking normal workflows.

Policy Advisor

The Policy Advisor is Truvant's AI-powered system for generating least-privilege policy roles. Instead of writing rules manually — a process that is slow, error-prone, and rarely kept up to date — the Advisor analyzes the actual behavior of your AI agents and generates concrete, evidence-based rule suggestions with confidence scores and per-change reasoning.

The Advisor runs on accumulated Monitor mode activity. The more behavioral data it has, the higher confidence its suggestions carry. New roles benefit from at least 48–72 hours of monitoring before requesting a suggestion; roles covering agents with regular, predictable workloads can converge faster.

How It Works

  1. Observe — Assign a host to a policy role in Monitor mode. The agent records every command and MCP tool call the AI agent attempts, along with its arguments, the session context, and whether it would have been blocked under a stricter rule set.
  2. Analyze — The Advisor processes the accumulated activity stream, clustering commands by binary, subcommand, and argument pattern. It identifies which operations are routine (high frequency, consistent arguments) and which are anomalous (one-off, risky argument patterns, or known dangerous subcommands).
  3. Recommend — The Advisor generates a full role suggestion: a set of rules that would allow all routine behavior and deny the anomalous or risky operations. Each proposed change includes a confidence percentage based on behavioral evidence, a risk level, and human-readable reasoning explaining why the change is recommended.
  4. Review — You review the full diff before anything changes. Every addition, removal, and modification is shown side by side with the Advisor's rationale. You can accept the full suggestion, accept individual changes, or discard what you disagree with.
  5. Apply — Accepted changes are merged into the role immediately and sync to all assigned hosts within seconds. The Advisor tracks which suggestions were accepted, rejected, or modified — this feedback improves future recommendations for your organization.

Role Suggestions

The Suggestions tab shows all pending and historical Advisor suggestions for your organization's roles. Each row represents one suggestion batch generated from a snapshot of behavioral data.

Column Description
Role The policy role this suggestion targets.
Hosts Number of hosts whose activity data was included in the analysis that produced this suggestion.
Changes Summary of proposed changes: +add new allow rules, ~modify existing rules, -remove overly broad permissions.
Confidence Overall confidence percentage for the suggestion batch, derived from the volume and consistency of the behavioral data used. Higher is more reliable.
Risk Aggregate risk level of the proposed changes. A high risk rating means some proposed removals or denies could break agent workflows if applied without review.
Date When this suggestion was generated.
Status Pending requires review. Applied has been merged into the role. Dismissed was discarded without applying.
Policy Advisor suggestions list showing role, host count, change summary, confidence percentage, risk level, and status
Policy Advisor — AI-generated role suggestions based on actual agent behavior

Reviewing a Suggestion

Click any pending suggestion to open the diff view. This is where you make the final call on every proposed change before it touches your policy.

The diff view uses a color-coded three-way format:

Each proposed change in the diff includes three pieces of information:

  1. Command pattern — The exact rule string that will be added, removed, or changed.
  2. Proposed action — Whether the rule will allow or deny the matched command.
  3. Reasoning — A plain-English explanation from the Advisor: how many times the command was observed, what arguments were used, why the change is recommended, and what the risk would be if the recommendation is incorrect.

You can accept or reject each change individually. If you want to accept most of a suggestion but disagree with one rule, you can apply the rest and discard only that change. Partial applications are tracked as "partially applied" in the suggestions list.

Suggestion detail diff view showing green additions, red removals, and yellow modifications with per-change reasoning
Suggestion detail — review every proposed rule change before applying
Least-privilege made practical The Policy Advisor turns the abstract principle of least-privilege into concrete, actionable rules. Instead of guessing what your agents need, let the Advisor analyze weeks of actual behavior and generate a tailored policy. You stay in full control — every change requires your explicit approval before it applies. This is the most direct mitigation for LLM06:2025 Excessive Agency: not broad, static permissions, but evidence-based, continuously refined rules that track how your agents actually work.

Advisor Settings

The Advisor can be configured from the Settings tab on the Policy Management page.

Variables — Environment Patterns

Variables let you assign hosts to named environments based on hostname regex patterns. Once assigned, environment variables can be referenced in policy rules to apply different levels of strictness to different parts of your fleet without maintaining separate, near-identical roles.

For example, a rule can reference {{env}} to apply a stricter pattern in production and a broader one in development, using a single shared role rather than duplicating it per environment.

Column Description
Value The environment name that will be substituted when the variable is referenced in a rule (e.g., production, staging, dev).
Patterns One or more hostname regex patterns. Any host whose hostname matches a pattern is assigned this environment value. Patterns are evaluated in order; first match wins.
Status Builtin variables are provided by Truvant and cannot be deleted (e.g., the default {{env}} variable). Custom variables are user-defined and can be edited or removed.
Used By The number of policy roles that reference this variable. Roles using a variable update automatically when the variable's patterns change.

Common use case: Apply strict enforcement to production hosts while allowing broader access on developer machines, using a single policy role. Set the production pattern to match your production hostname prefix (e.g., ^prod-.*) and the dev pattern to match developer machines (e.g., ^dev-.* or ^[a-z]+-mbp.*). Reference the variable in your role's command rules to gate high-risk operations on environment context.

Variables page showing environment pattern assignments with value, hostname regex patterns, status, and usage count
Variables — assign hosts to environments by hostname pattern