Security belongs at the point of execution.
AI systems can generate plans, select tools, and request operations across connected services. Securing the model's output alone does not determine whether a requested operation should be permitted.
SAILLENT is engineered around a separate enforcement boundary: evaluate covered requests against explicit policies and control whether they proceed through the protected execution path.
Intercept. Inspect. Enforce.
The enforcement architecture
Model requests and tool executions are distinct paths. Direct calls bypass the enforcement boundary and require separate controls.
SAILLENT introduces a runtime policy evaluation layer into configured AI request paths.
Request
An AI application or agent sends a request through a configured SAILLENT interface.
Interception
The runtime receives the request on the protected path. Requests that bypass the runtime are outside that path's coverage.
Policy evaluation
The runtime evaluates request context against applicable policy rules.
Decision
The runtime determines whether the covered operation is allowed or denied.
Forward or block
Allowed requests proceed through the configured path. Denied requests are prevented from proceeding.
Audit
The decision and available context are recorded, subject to deployed configuration.
Reproducible Test Scenario: Unauthorized Tool Execution
To validate enforcement behavior, we simulate an agent attempting an action outside its permitted scope. This demonstrates the runtime's decision logic, audit output, and failure handling.
# 1. Test Setup Agent Role: payment-operations Target Tool: payments.create_instruction Requested Action: Write Active Policy: payments-production (v14) — allowed_actions: [Read] # 2. Runtime Evaluation Intercept: Request captured at configured enforcement boundary. Inspect: Context matched against policy v14. Decision: DENY (Action 'Write' not in allowed_actions for this agent_role). # 3. Enforcement Action Forward/Block: Request blocked. Upstream tool not invoked. Audit Record: Logged to local SQLite + SIEM export (if configured). { "timestamp": "2026-10-10T14:22:01Z", "agent_id": "payment-ops-agent-01", "tool_id": "payments.create_instruction", "policy_id": "payments-production", "policy_version": 14, "decision": "DENY", "reason": "Action not permitted by active policy" }
Note: This is a controlled, simulated test scenario. Actual audit schemas and runtime versions depend on your deployed configuration. View full testing methodology →
Model requests and tool executions are distinct paths with distinct enforcement points. Exact routing depends on deployment configuration.
Policy as code
Security policies should be explicit, reviewable, and operationally manageable. SAILLENT uses structured policies to describe which operations are permitted for configured agent and tool contexts. A published policy example:
policy: id: payments-production version: 14 agent_role: payment-operations tool_id: payments.create_instruction allowed_actions: - Read risk_level: high is_active: true
| Field | Purpose |
|---|---|
| id / version | Identify the rule and its revision, so decision records can reference the exact policy evaluated. |
| agent_role | The agent context to which the rule applies. |
| tool_id | The tool or operation covered by the rule. |
| allowed_actions | Permitted action categories for this agent-tool pair. |
| risk_level | Risk classification applied to the covered operation. |
| is_active | Whether the policy is currently enabled. |
This example reflects SAILLENT's published policy structure. Consult the technical documentation for the complete schema of your deployed runtime version, including how empty or absent allowed_actions are interpreted.
Default-deny design
A default-deny policy model denies requests that do not match an applicable permission rule. This reduces reliance on implicit authorization — it does not, by itself, prove that every possible action is covered or that every failure condition is handled securely.
Policy lifecycle
The runtime design supports policy updates from a configured policy source, with periodic refresh and last-known-good behavior when that source becomes unavailable. The exact behavior depends on the failure condition: startup without a valid policy, malformed policy updates, runtime failures, and downstream connectivity failures must each be evaluated separately. See deployment documentation for the documented behavior of each case.
Enforcement, not just observation
Monitoring can show that an operation was attempted. Runtime enforcement can control whether a covered operation proceeds.
| Capability | Engineering purpose |
|---|---|
| Request interception | Bring covered operations into the enforcement path |
| Policy evaluation | Apply explicit authorization rules |
| Allow or deny | Control whether a covered request proceeds |
| Policy versioning | Identify which policy revision was active at decision time |
| Decision records | Support investigation and operational review |
| Policy refresh | Apply supported policy updates without a full redeployment |
These capabilities do not eliminate the need for IAM, secure credentials, network controls, monitoring, or application-level authorization.
Security boundaries and failure behavior
A security control must be evaluated not only by what happens during normal operation, but also by what happens when dependencies fail. These are separate cases with separate behaviors:
Coverage boundaries
SAILLENT enforces only on execution paths that pass through its configured enforcement point. Direct provider calls, alternate credentials, and unprotected tools are bypass paths that need separate controls.
Policy-source failures
When the configured policy source is unavailable, documented last-known-good behavior preserves the previously loaded policy state. This is not a universal guarantee for every startup, parsing, or storage failure.
Downstream failures
Provider timeouts, network failures, malformed responses, and unavailable tools affect whether a request completes — distinct from the policy decision itself.
Audit failures
Audit storage and enforcement decisions are distinct concerns. Understand what happens if audit persistence fails, whether the request continues, and what evidence may be missing.
License and service availability
Licensing, hosted control-plane availability, and runtime enforcement are separate architectural concerns. Deployment documentation states the actual behavior for expired licenses, revocation, connectivity loss, and recovery.
Performance engineering
Runtime enforcement adds work to a request path. Its performance must be measured under representative workloads rather than described with unsupported latency claims. A meaningful benchmark documents:
- Runtime version and build; hardware, OS, and deployment topology
- Request and response sizes; policy complexity and matching behavior
- Concurrency, throughput, and latency percentiles (p50, p95, p99)
- Error rates and test duration
- Whether measurements include upstream model-provider latency or only runtime overhead
We publish performance figures only when they are supported by reproducible measurements and a clearly described methodology.
Auditability and operational evidence
A policy decision is more useful when operators can investigate why it occurred. Depending on the configured audit schema, decision records can support analysis of:
- The agent and tool context associated with a request
- The decision made by the runtime and the policy associated with it
- The recorded reason or matching context
- Relevant timestamps and available request metadata
Audit records should not automatically be described as immutable or tamper-proof. Those properties depend on storage architecture, permissions, integrity controls, retention configuration, and independent verification. For production deployments, define retention requirements, access restrictions, export needs, and the relationship between runtime logs and your SIEM or incident-response processes.
Built for defense in depth
Identity and access management
Establishes who or what can authenticate and which permissions it holds.
Runtime enforcement
Evaluates covered requests against configured policies at the protected execution boundary.
Monitoring and incident response
Detects suspicious behavior, investigates events, and coordinates response.
Governance and change management
Establishes how policies are approved, reviewed, deployed, and maintained.
No single layer replaces the others. The overall security outcome depends on the architecture, configuration, coverage, and operation of the combined controls.
Technical transparency
We believe security infrastructure should be evaluated on verifiable behavior rather than broad promises. For technical evaluations, we can discuss the applicable runtime version, supported interfaces, policy schema, deployment model, failure behavior, audit fields, and available test evidence. Claims about performance, security assurance, certifications, or comprehensive attack prevention should be supported by evidence appropriate to the specific claim.
Engineering questions
Does SAILLENT inspect every prompt?
Coverage depends on how requests are routed and which interfaces are configured. Do not assume every prompt, model call, or tool operation is inspected simply because SAILLENT is installed.
Does SAILLENT determine whether an AI model is telling the truth?
No. SAILLENT's core enforcement role is to evaluate covered requests against configured policies. This is distinct from proving the factual correctness of model output.
Does SAILLENT replace an identity provider or policy framework?
No. It adds runtime enforcement to configured request paths and should be integrated with your broader identity and security architecture.
What happens when a policy source is unavailable?
The runtime supports last-known-good policy behavior when its configured policy source becomes unreachable. Other failure conditions have their own behavior and are reviewed in the applicable technical documentation.
Can the runtime operate without a hosted dashboard?
Deployment and licensing dependencies vary by supported configuration. Consult the current deployment documentation before assuming any hosted service is optional for a particular installation.
Where can I find implementation details?
The technical documentation is the reference for installation, configuration, policy schemas, supported interfaces, deployment, and troubleshooting.
Build with a clear enforcement boundary.
Explore the technical documentation or speak with our team about your deployment architecture and enforcement requirements.
