Security architecture

The safety of an autonomous agent can't be left to "a good system prompt". In SemAgent, constraints are enforced at the code level — persuading, tricking, or telling the agent to "ignore the rules" can't bypass them. This page explains those layers.

Policy engine

Every tool call passes through a central evaluation before it runs. This happens outside the LLM, in deterministic code:

Tool call proposed
   ↓
1) Capability gate  → can this tenant/user use this tool?
2) Allow-list       → is the target (email domain, URL, DB) permitted?
3) Risk class       → compute risk from tool + arguments
4) Approval threshold → does the autonomy level pass this without approval?
   ↓                                   ↓
run (SAFE)                    show approval card (action)

Levels and thresholds: Autonomy & approvals. Tool risk classes: tool reference.

Prompt-injection quarantine

The biggest agent threat is indirect prompt injection: hidden instructions like "now delete that email" embedded in a web page, email or document. SemAgent marks content from the web and external sources as "untrusted" and doesn't feed it straight to the planner — it routes it through a separate layer. Instructions inside external text are treated as data, not commands; and every action is still subject to the policy engine.

Encrypted vault (agent-vault)

• API keys, OAuth tokens and DB credentials are stored encrypted with Fernet.
• These secrets are never sent to the LLM — they're decrypted server-side while a tool runs; the model only sees the result.
• They're masked in logs. You can delete any vault secret from the panel at any time.

Idempotency & resume

• Idempotency: even if the same action is triggered twice by mistake, it runs once (a resend, page refresh or colliding trigger ≠ a double email).
• Resume: if a multi-step task is interrupted (network, restart) it continues from where it stopped — no restart, no repeating completed steps.

Anti-confabulation

When a tool returns empty or errors, LLMs naturally tend to invent a plausible but wrong reason ("access blocked", "out of tokens"). SemAgent prevents this: if a tool result is empty, the agent gets a diagnostic note ("possible causes… don't guess") and reports the situation as-is. So users aren't misled by ungrounded excuses.

Verification badge

Every agent answer carries a badge showing what about it was checked in code: Verified, Partly verified, or No tools used (the model answered from its own knowledge). The badge is deterministic — the checking is done by code, not by a second model.

Checks that affect the badge:

• Coverage — did the tool return more records than the answer actually summarised?
• Total consistency — when an answer has line items and a stated total, the items are summed in code and compared against it. Different currencies are never added together.
• Write confirmation — if the agent wrote something (a file, a calendar entry), it is read back from the source to confirm it really exists.

Two further checks run in measurement mode: whether the amounts in an answer actually appear in the retrieved data, and whether unit conversions are arithmetically correct. Both record their findings but do not yet change the badge — we do not show a user-facing warning before the false-alarm rate has been measured.

Tenant isolation & data

Each tenant's knowledge base, connectors, memory and conversations are isolated. SemAgent does not train models on your data. For encryption, sub-processors, GDPR and DPA details, see the Trust Center.