Skip to main content

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

​
The data model

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:
  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: 
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/:
RuleCategoryWhat it catches
InstructionBypassInstruction Bypass”Ignore previous instructions”, “Disregard the above…”, and dozens of paraphrases.
GenericSecretSecretsHigh-entropy hex / base64 patterns suggestive of API keys.
ApiTokensSecretsCommon token shapes (Slack, GitHub, Stripe, etc.).
SshKeySecretsOpenSSH / RSA private-key block headers.
IpAddressNetworkIPv4 / IPv6 patterns.
MarkdownExfiltrationExfiltrationMarkdown image-link tricks used for OOB data theft.
FakeItMaintenanceSocial EngineeringCommon helpdesk-impersonation phrasings.
SystemInstructionsInjectionAttempts to inject system: / assistant: role markers into a user prompt.
React / ReactTxtFormatCommon React / JSX patterns.
GuidanceInjectionMicrosoft “guidance” template patterns used in some attacks.
ExtortionThreatsExtortion / 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:
  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: 
{
  "name": "yara_analyzer",
  "params": { "yara_policy_id": "<uuid-of-yara-policy>" }
}
You can also override per-request without baking the ID into the 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>"
  }'
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

RoleReadCreate / updateDelete
OwnerYesYesYes
AdminYesYesYes
MemberYesYesYes
ViewerYesNoNo
Both rules and policies follow the yara:* scope family. See Roles & 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