YARA rules and policies

• YARA rules — individual .yar rules, owned by a tenant.
• YARA policies — named groupings of rules. The YARA analyzer targets a specific policy, so a single combined policy can swap rule sets per route, per product, or per traffic type.

​

The data model

​

Authoring a rule

1. Click New rule.
2. Give it a unique name; the YARA rule body must declare the same identifier (rule MyRule: …).
3. Paste or write the rule. The editor validates compilation in-browser before save.
4. Optionally toggle Active. Inactive rules are not compiled into any policy; useful for staging risky rules.
5. Save.

rule InternalCodename: Confidentiality
{
    meta:
        category    = "Confidential"
        description = "Detects an internal product codename."

    strings:
        $codename = "Project Cernunnos"

    condition:
        $codename
}

• The first identifier after rule must match the rule’s name in Agnes’s database; the dashboard enforces this.
• The meta: category = value is what shows up as a termination signal under “Rule Category”. Reuse a stable set of categories (Injection, Secrets, Confidentiality, Brand, etc.) so policy authors can target a category instead of an explosion of rule names.

​

Generating rules from samples

​

Built-in rules

​

Authoring a YARA policy

1. Click New policy.
2. Give it a name and (optional) description.
3. Add rules to the policy in the order you want them evaluated.
4. Optionally mark as the tenant default YARA policy. The default is used by the YARA analyzer when no yara_policy_id is set.
5. Save.

• Inbound base — the system instruction-bypass rules + your own product-specific injections.
• Outbound base — the secrets and exfiltration rules + your internal codenames.
• High-risk surface — every rule, even noisy ones; pair with a combined policy that treats matches_found > 0 as a block.

​

Wiring it into a combined policy

{
  "name": "yara_analyzer",
  "params": { "yara_policy_id": "<uuid-of-yara-policy>" }
}

curl -X POST https://api.lasscyber.com/api/v1/analyze/ \
  -H "Authorization: Bearer ak_…" \
  -H "Content-Type: application/json" \
  -d '{
    "prompt": "...",
    "policy_slug": "default-inbound",
    "yara_policy_id": "<uuid>"
  }'

​

Permissions

​

Limits and gotchas

• Compilation cache. Agnes compiles the policy on first use and caches it per tenant + policy. Adding or disabling a rule clears the cache lazily; the next request after the change recompiles.
• Quoting. YARA strings use /regex/-style literals or double-quoted strings. Test rules locally with the official YARA CLI when uncertain.
• Performance. A few hundred well-written rules is fine; tens of thousands of overlapping regex rules will measurably degrade latency. Group, don’t duplicate.

​

Next

• YARA analyzer — runtime metrics, termination signals, and latency.
• Combined analyzer — wire the YARA policy into termination rules.