SAILLENT Technical Documentation

Introduction

SAILLENT is a runtime enforcement layer for autonomous AI agents that controls requests traversing a configured enforcement path to downstream tools, APIs, and services.

SAILLENT intercepts requests, evaluates them against a GitOps-driven policy engine, and enforces a decision before the action executes.

The enforcement model is: Intercept → Inspect → Enforce

For each intercepted request, SAILLENT determines whether the action is permitted by the active policy set. Policy evaluation produces one of two decisions:

• Allow — permit the request to continue to the upstream service.
• Deny — prevent the action from executing. Return an error to the caller.

Separately, the inspection layer can apply Redact — modifying protected content (e.g., PII) before forwarding — when configured PII controls match. Redact is an inspection-layer action; it is not a policy decision and is not selectable through allowed_actions.

Upstream service: the external API, tool, or service to which SAILLENT forwards an admitted request.

Each enforcement decision is written to the local audit store together with the Git commit associated with the policy bundle currently loaded by the runtime.

Architecture

The runtime engine is deployed as a native Linux binary within the customer's infrastructure. It handles traffic locally before it reaches the configured upstream service. Policy state is synchronized from a Git repository every 60 seconds.

Quick Start

Requirements

• Linux-based host (Ubuntu 20.04+, RHEL 8+, or equivalent)
• sudo privileges
• Outbound network access to license.saillent.com (enrollment and heartbeat)
• A valid SAILLENT enrollment token (generated from the organization dashboard)

Step 1: Deploy the Runtime Engine

SAILLENT deploys as a compiled Rust binary. No container runtime is required.

curl -fsSL https://get.saillent.com | sudo bash -s -- <YOUR_ENROLLMENT_TOKEN>

Step 2: Verify Installation

# Check service status
sudo systemctl status saillent

# View real-time enforcement logs
sudo journalctl -u saillent -f

# Inspect the local audit database
sudo sqlite3 /opt/saillent/saillent.db "SELECT decision, reason FROM audits ORDER BY id DESC LIMIT 5;"

Step 3: Define Your First Policy

Policies are managed via Git. Create a file in your policy repository:

id: "analyst-postgres-001"
version: "1.0.0"
description: "Allow data analysts to read from postgres, block destructive actions"
agent_role: "data_analyst"
tool_id: "postgres_db"
allowed_actions:
  - Read
conditions:
  - MaxRiskScore: 50
  - PayloadRegexDeny: "(?i)(DROP|DELETE|TRUNCATE)"
priority: 100
is_active: true

Request Lifecycle

Every request traversing the configured SAILLENT enforcement path passes through the following sequential pipeline:

Normalization Pipeline

Before security inspection, SAILLENT applies the following transformations to detect and reduce representation-based evasion. These are applied in order:

Policy Schema

Policies are YAML documents validated by the Rust PolicyEngine before loading. The following fields are defined in saillent-core/src/policy.rs:

Supported Conditions

Policy Evaluation Algorithm

Policies sorted by priority descending
             ↓
Evaluate highest priority policy
             ↓
Match?
 ├── No → next policy
 └── Yes
       ↓
    Policy decision (Allow/Deny)
       ↓
    STOP (first match determines outcome)

• Default deny: If no policy matches an action, the default behavior is to Deny.
• Validation gate: If a new policy fails schema validation or regex compilation, the update is rejected. The engine retains the last-known-good policy state.

Enforcement

Enforcement outcomes combine the policy decision (Allow or Deny) with any inspection-layer redaction applied to admitted requests.

Allow

The request is forwarded to the configured upstream service without modification. The decision is logged to the audit store.

Redact

Redact is an inspection-layer action triggered by configured PII controls. It is not one of the values in allowed_actions. A YAML policy cannot select Redact: policy evaluation yields only Allow or Deny. An allowed request may still have PII redacted before forwarding.

When the inspection layer detects matched PII patterns in the payload, those patterns are replaced with redaction tokens before forwarding:

• Email addresses → [REDACTED_EMAIL]
• Social Security Numbers → [REDACTED_SSN]
• Credit Card Numbers → [REDACTED_CC]

Deny

The request is not forwarded. The caller receives a JSON error response with the decision code and reason. The specific HTTP status depends on the denial cause (e.g., 403 for policy violation, 413 for oversized payload, 429 for concurrency limit).

Supported Runtime Interfaces

SAILLENT can inspect and enforce policies on the following traffic types:

Resource Limits

Failure Behavior

SAILLENT uses fail-closed behavior for policy enforcement decisions. Auxiliary subsystem failures are handled according to the failure behavior documented below.

Policy-state Traceability

Each enforcement decision is written to the local SQLite audit store. Each record contains:

Threat Model

Assets

• Agent permissions
• Tool access
• Enterprise data
• API credentials
• Database operations
• Policy configuration
• Audit records

Threats

• Compromised agent
• Prompt-induced malicious action
• Malicious tool invocation
• Encoded payload evasion
• Unicode/representation evasion
• Unauthorized destructive operation
• Policy tampering
• Malformed policy deployment
• Resource exhaustion

Trust Assumptions

SAILLENT trusts:

• The runtime host
• The operating system
• The SAILLENT runtime binary
• The configured policy repository / policy source
• The licensing service (license.saillent.com) used for enrollment token validation and heartbeat

Security Boundary

Security Properties

Explicit Non-Goals

What SAILLENT Does Not Do

• SAILLENT does not replace Identity and Access Management (IAM). It enforces policies on top of existing identity systems.
• SAILLENT does not determine whether an LLM response is factually correct.
• SAILLENT does not guarantee that an agent is uncompromised.
• SAILLENT does not replace network segmentation or network firewalls.
• SAILLENT does not automatically make an application compliant with a regulatory framework. It provides audit artifacts and enforcement controls that support compliance efforts.
• SAILLENT does not attempt to make an AI model inherently trustworthy. It establishes an external control boundary around the actions the agent is permitted to execute.

SAILLENT is not

• an LLM
• an LLM gateway by itself
• an IAM system
• a network firewall
• an EDR
• a SIEM
• a replacement for application authorization
• a guarantee of model safety