Lifecycle
Policies are tenant-scoped. Two tenants can have different policies under the same slug; an API key for tenant A can never reach tenant B’s policies.Where they live
- In the dashboard at
agnes.lasscyber.com/protection/policies. Schema-driven editor with full coverage of analyzer parameters, metric thresholds, and termination signals. - In code via the SDKs — see
PolicyBuilder. - Via raw API —
GET / POST / PUT / DELETE /api/v1/policies/. See the auto-generated API reference.
Built-in policies
Every new tenant inherits three defaults so you can callanalyze
immediately without authoring anything:
| Slug | is_default | Purpose |
|---|---|---|
default-inbound | Yes (inbound) | Strict guard for user prompts before they reach your LLM. Strong termination on prompt injection / safety / SDP / URL / YARA findings. |
default-outbound | Yes (outbound) | Same analyzers reordered to weight safety + SDP + URL on the way back to your user. |
default-permissive | No | Same analyzers but every termination rule is proceed_to_next_step. Useful for shadow rollouts. |
is_default flag is per direction: each tenant has at most one
default-inbound and one default-outbound. The guard() helper in both
SDKs auto-flips between them when you call check_input /
check_output.
You can clone any of these defaults into a custom policy and adjust:
Schema
The full schema lives inapi/models/config_schema.py;
the auto-generated API reference renders the
JSON Schema. The fields you care about most:
| Field | Purpose |
|---|---|
name | Human-readable display name. |
slug | Stable, URL-safe identifier. SDK policy= lookups use this. |
description | One-paragraph summary. Surfaced in the dashboard list. |
is_default | Marks this as the tenant default for its direction. |
available_analyzers | Array of { name, params } declaring which analyzers may run. |
execution_plan | Array of steps, each with type (sequential / asynchronous) and analyzers. |
termination_conditions | Per-analyzer rules: output match, thresholds, logical operator, on-match action. |
default_telemetry | When true, sums analyzer cost into the response’s aggregated metrics. |
Versioning
Combined policies are not strictly versioned today. EachPUT
overwrites the existing record. The pattern we recommend:
- Treat policy slugs as your version handle. Ship
inbound-strict-v1andinbound-strict-v2side by side; flip your callers when you are ready. - Use the analyzer log to monitor decisions before promoting a new
slug to
is_default. - Never edit
default-inbound/default-outbounddirectly — clone them and rename the clone before changing thresholds. The defaults are reset to the shipped values on tenant re-provisioning.
policy_version field on responses) is on the roadmap. If
you need it, talk to sales@lasscyber.com.
Importing and exporting
The dashboard policy editor exposes Export and Import buttons that round-trip the policy as JSON. Import preservesname, slug,
description, available_analyzers, execution_plan, and
termination_conditions; it ignores id, tenant_id, and timestamps
because those are server-managed.
The same JSON imports cleanly via agnes.policies.create(...) in both
SDKs.
Permissions
Per the role matrix:| Role | Read | Create / update | Delete |
|---|---|---|---|
| Owner | Yes | Yes | Yes |
| Admin | Yes | Yes | Yes |
| Member | Yes | Yes | Yes |
| Viewer | Yes | No | No |
Common patterns
- One inbound policy per product surface. A consumer chatbot, an internal copilot, and a compliance-controlled workflow probably want three different inbound policies, even if they share most analyzers.
- Outbound policies should be stricter on safety + SDP, looser on prompt injection. The classifier overfires on quoted user text in outputs.
- Use
default-permissivefor shadow rollouts. Run the policy you intend to ship inproceed_to_next_stepmode for a week; review the analysis log; promote.
Next
- The Agnes Analyzer — execution plan and termination rules.
- API reference —
GET/POST/PUT/DELETE /api/v1/policies/. - Sandbox mode — exercise policies in CI without billing.