Securing agents

Availability

Open core · redaction, detection, and the inline guard run on all plans. The governance steps are Cloud & Enterprise — the audit ledger and spend limits require the Team plan and up; the policy engine requires Enterprise.

Securing an agent is a progression, not a single switch. This guide walks the four layers in the order you should adopt them: redact sensitive data, block the highest- confidence attacks inline, review what got flagged, and finally require an authorization decision before an agent takes a consequential action.

1. Redact by default

Every Splyntra SDK ships with client-side redaction on — high-confidence secrets are stripped from spans before they leave your process. Keep it on in production and make the intent explicit:

from splyntra import Splyntra

Splyntra(
    api_key=...,
    project="support-agent",
    redact_by_default=True,   # default; pinned here to be explicit
)

The detection pipeline still scores risk on every plan, so PII and secret findings appear on the run even when the raw values never leave your machine. See Detection & redaction.

2. Turn on the guard in block mode

The inline guard runs a high-precision prompt-injection pre-flight. In "monitor" it flags; in "block" it raises SplyntraBlocked and stops the call before it reaches the model:

from splyntra import Splyntra, SplyntraBlocked

Splyntra(api_key=..., project="support-agent", guard="block")

try:
    run_agent(user_input)
except SplyntraBlocked:
    # Reject the request — an injection attempt was caught pre-flight.
    ...

The guard is fail-open by default (guard_fail_open=True): if the guard service is unreachable, the call is allowed so an outage never takes your agent down. Set it to fail-closed if blocking is more important than availability. See Guardrails.

3. Review incidents

Once traffic flows, open the Security dashboard to review incidents — prompt injection, leaked secrets, PII, content-moderation hits, and unsafe tool calls — each linked to the exact span that triggered it. Use it to tune what you block versus monitor. See Security overview.

note

The Security dashboard (secret/PII and injection detection views) requires the Pro plan or higher on Cloud; the redaction and risk-scoring pipeline itself runs on every plan.

4. Authorize consequential actions

Detection and guarding protect the inputs. For actions with real-world consequences — a refund, a data export, a deploy — add a governance authorize() check that the agent must pass first:

from splyntra import authorize

decision = authorize(
    "payments.refund",
    agent_id="support_agent",
    context={"amount": 80},
)
if decision["decision"] != "allow":
    # "deny" or "needs_approval" — do not proceed.
    ...

authorize() evaluates, in order: an explicit agent deny, the agent's spend limit (Team+), the policy engine's deny-wins rules (Enterprise), and any matching approval rule (which returns needs_approval). Every outcome — allow, deny, or needs-approval — is written to the append-only audit ledger, giving you a hash-chained record of what each agent was permitted to do.

Record non-authorization events with log_action():

from splyntra import log_action

log_action("refund", actor="support_agent", resource="ticket_123", metadata={"amount": 80})

See Governance overview, Delegation & approvals, and the Activity ledger.

Putting it together

Layer	Mechanism	Availability
Redact sensitive data	redact_by_default=True	All plans
Block injection inline	guard="block"	All plans
Review what was flagged	Security dashboard	Pro+ (Cloud)
Authorize actions + audit	authorize() + audit ledger	Team+ / Enterprise

Next steps

• Detection & redaction — what the pipeline detects.
• Guardrails — guard modes in depth.
• Policy engine — RBAC/ABAC/ReBAC rules.
• Compliance — turn the ledger into reports.