Starfort

AI agents send Logpresso data such as user questions and query results to their models. Once the AIM Starfort app is installed, it registers itself with the AI agent app as a guardrail, and what goes to the model is inspected with Starfort first. Personal data is masked before it is sent, and a BLOCK verdict or a failed inspection stops the run.

Before you start

• AI agent app - The AI Assistant or Agentic SOC app 1.13 or later
• AIM Starfort connect profile - At least one

There is no setting. With both in place the guardrail is on; it turns off when the app is removed or every AIM Starfort connect profile is deleted. With several connect profiles, the first one by identifier is used.

Checking the status

Open the Guardrails tab of the AI Agents menu and click the gear at the top right to open Guardrail status.

• Active at the top means the guardrail is on
• Each registered guardrail shows its stages, whether it is Ready, and the connect profile in use
• Not ready comes with the reason, for example that no AIM Starfort connect profile exists

What is inspected

While the guardrail is on, everything below that goes to the model is inspected.

Masking and restoring

Values Starfort masked are replaced with placeholders such as {{PHONE_NUMBER_1}} and {{EMAIL_2}} before they reach the model. The same value always gets the same placeholder within a run. The model is told to use the placeholders exactly as written.

What the model writes with placeholders is restored to the original values right before it is used.

• Right before a query runs - the search uses the real values
• The approval prompt - the approver sees the query that will actually run
• Sub-agent input and HTML reports
• The final answer - the user receives the answer with the original values

Failure handling

In the following cases the agent run ends as failed, with a reason distinct from ordinary failures.

A failed inspection also always stops the run, so content that could not be checked is never sent to the model. Query commands such as sonar-ai-ask report 420050 (blocked) and 420051 (could not inspect).

Run details

Each turn in the agent run details shows its guardrail record.

• Guardrail · N check(s) · N masked value(s) · N restored - the turn's checks and placeholders
• Original / As sent to LLM switch - Original by default. As sent to LLM shows the placeholder form the model actually received. It applies to the reasoning, findings, tool queries and tool results
• A turn that was blocked or failed inspection shows BLOCK or the error kind in red

A run with guardrail records has a Guardrail logs button at the top that opens the audit log of that run.

Guardrail audit log

Every guardrail API call writes one audit log row, whether it succeeded or failed. Rows include the matched originals, so only administrators can read them.

Screen

Open the Guardrails tab of the AI Agents menu.

• Filter by period, agent code, source, verdict and Failures only at the top
• The list shows time, agent, run, source, provider (connect profile), verdict, findings and latency. A failed call shows its error kind instead of a verdict
• Click a row to expand the findings (original, value sent to the model, type, rule, message), the request ID and the error
• Click the run column to open that agent run

Query

The sonar-ai-guardrail-logs command reads the same log. It reads your company's audit log table, so the rest of the pipeline can search and aggregate it like any table.

sonar-ai-guardrail-logs duration=7d | search agent_code == "phishing-triage"

sonar-ai-guardrail-logs duration=7d | search isnotnull(error_kind) | stats count by provider, error_code

A row without error_kind is a successful call. See the command help on the query screen for the fields.