> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lasscyber.com/llms.txt
> Use this file to discover all available pages before exploring further.

# YARA rules and policies

> Author YARA rules, group them into policies, and wire them into the YARA analyzer.

[YARA](https://virustotal.github.io/yara/) is the rule engine you reach
for when an attacker's pattern is well-defined and you want
deterministic enforcement. Agnes manages YARA at two levels:

* **YARA rules** — individual `.yar` rules, owned by a tenant.
* **YARA policies** — named groupings of rules. The
  [YARA analyzer](/analyzers/yara) targets a specific policy, so a
  single combined policy can swap rule sets per route, per product, or
  per traffic type.

This page is the workflow reference. The analyzer-level details
(metrics, termination signals, latency) live on
[YARA Rule Enforcement](/analyzers/yara).

## The data model

```mermaid theme={null}
flowchart LR
    Rule1[YARA rule] -.belongs_to.-> Tenant[Tenant]
    Rule2[YARA rule] -.belongs_to.-> Tenant
    Rule3[YARA rule] -.belongs_to.-> Tenant
    Pol1[YARA policy] -.contains.-> Rule1
    Pol1 -.contains.-> Rule2
    Pol2[YARA policy] -.contains.-> Rule2
    Pol2 -.contains.-> Rule3
```

A rule is independent of any policy. A policy is just a named ordered
set of rule references. A rule can appear in many policies. Deleting
a policy does not delete its rules.

## Authoring a rule

In the dashboard at
[`agnes.lasscyber.com/protection/yara`](https://agnes.lasscyber.com/protection/yara):

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.

A minimal rule:

```yara theme={null}
rule InternalCodename: Confidentiality
{
    meta:
        category    = "Confidential"
        description = "Detects an internal product codename."

    strings:
        $codename = "Project Cernunnos"

    condition:
        $codename
}
```

Two conventions to follow:

* 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

The dashboard has a **Generate from samples** action that takes a list
of example malicious texts and produces a starting YARA rule. It is a
helper, not a substitute for review — always read the generated rule
before activating it.

## Built-in rules

Agnes ships a handful of system-level rules under
[`api/data/yara/`](https://github.com/lasscyber/agnes-docs/tree/main/yara-fixtures):

| Rule                   | Category           | What it catches                                                                    |
| ---------------------- | ------------------ | ---------------------------------------------------------------------------------- |
| `InstructionBypass`    | Instruction Bypass | "Ignore previous instructions", "Disregard the above…", and dozens of paraphrases. |
| `GenericSecret`        | Secrets            | High-entropy hex / base64 patterns suggestive of API keys.                         |
| `ApiTokens`            | Secrets            | Common token shapes (Slack, GitHub, Stripe, etc.).                                 |
| `SshKey`               | Secrets            | OpenSSH / RSA private-key block headers.                                           |
| `IpAddress`            | Network            | IPv4 / IPv6 patterns.                                                              |
| `MarkdownExfiltration` | Exfiltration       | Markdown image-link tricks used for OOB data theft.                                |
| `FakeItMaintenance`    | Social Engineering | Common helpdesk-impersonation phrasings.                                           |
| `SystemInstructions`   | Injection          | Attempts to inject `system:` / `assistant:` role markers into a user prompt.       |
| `React` / `ReactTxt`   | Format             | Common React / JSX patterns.                                                       |
| `Guidance`             | Injection          | Microsoft "guidance" template patterns used in some attacks.                       |
| `Extortion`            | Threats            | Extortion / blackmail patterns.                                                    |

System rules are read-only; you can disable them per tenant if they
fire on legitimate traffic in your domain.

## Authoring a YARA policy

In the dashboard at
[`agnes.lasscyber.com/protection/yara-policies`](https://agnes.lasscyber.com/protection/yara-policies):

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.

Common groupings to consider:

* **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

The YARA analyzer takes a `yara_policy_id` parameter:

```json theme={null}
{
  "name": "yara_analyzer",
  "params": { "yara_policy_id": "<uuid-of-yara-policy>" }
}
```

You can also override per-request without baking the ID into the
policy:

```bash theme={null}
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>"
  }'
```

Per-request overrides are useful for shadow testing — point a fraction
of traffic at a candidate rule set, watch the analyzer log, promote
when ready.

## Permissions

| Role   | Read | Create / update | Delete |
| ------ | ---- | --------------- | ------ |
| Owner  | Yes  | Yes             | Yes    |
| Admin  | Yes  | Yes             | Yes    |
| Member | Yes  | Yes             | Yes    |
| Viewer | Yes  | No              | No     |

Both rules and policies follow the `yara:*` scope family. See
[Roles & permissions](/administration/roles-and-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](/analyzers/yara) — runtime metrics, termination
  signals, and latency.
* [Combined analyzer](/concepts/combined-analyzer) — wire the YARA
  policy into termination rules.