Business Context Rules
Suppress what you know is safe. Escalate what matters.
Business context rules are declarative statements about your organization: which accounts are privileged, which IPs are trusted, which data stores are in scope for PCI, which teams work late. Detections and agents read this context at evaluation time.
Business context DSL — YAML
Rules in plain language, not regular expressions
Context rules declare facts about your environment. Each fact is tagged with the entities it applies to and the data sources used to evaluate it. Detection rules and agents reference fact names, not the underlying logic.
business_context:
- id: trusted_build_agents
description: "IPs belonging to CI build agents — expected to call ECR at high volume"
type: ip_range_list
applies_to: event.source_ip
values:
- 10.32.0.0/16
- 10.33.0.0/16
effect:
suppress_findings:
- ecr-high-volume-pull
reduce_blast_radius_multiplier: 0.1
- id: pci_scope_datastores
description: "S3 buckets and RDS instances in scope for PCI DSS"
type: asset_tag_match
match:
tag.data_classification: pci
effect:
escalate_severity: +1 # medium → high, high → critical
require_mfa_on_access: true
- id: after_hours_operations
description: "On-call window: team works 24/7, no geography anomaly expected"
type: schedule
applies_to: entity.team_tag
team_tag: security-oncall
schedule:
timezone: UTC
always: true
effect:
suppress_geo_anomaly: true
- id: privileged_accounts
description: "Human accounts with standing admin access across production"
type: entity_list
source: ldap_group
ldap_group: "CN=ProdAdmins,OU=Groups,DC=corp,DC=example"
effect:
blast_radius_multiplier: 2.0
require_approval_for_autonomous_actions: trueThree types of business context
Suppression context
Declare that a known-safe pattern should not generate noise. CI build agents pulling images from ECR at high volume, security scanners making hundreds of API calls, and backup jobs accessing storage at 3 am are all suppressible by a single rule referencing the relevant IP ranges, account IDs, or schedule.
- Suppression is explicit and auditable — not a filter you forget about
- Suppression rules have expiry dates to prevent permanent blind spots
- Suppressed events are still stored; suppression affects finding generation only
Suppression context
Escalation context
Declare that activity involving certain assets should always escalate to the next severity level. PCI-in-scope databases, secrets managers, domain controller accounts, and production payment APIs are tagged, and any detection touching them automatically escalates — without modifying individual detection rules.
- Escalation applies across all detection rules simultaneously
- Escalation is additive: +1 severity level, not an override
- Escalation context is visible in the finding card so analysts understand why
Escalation context
Enrichment context
Teach the platform about your org structure: which LDAP groups are privileged, which Slack channels map to which teams, which cost centers own which cloud accounts. This context is referenced by investigation agents to add business impact language to verdicts and reports.
- LDAP, Azure AD, and Okta group sync for real-time group membership
- Cost center and business unit tags from HR system integration
- Environment tags (prod, staging, sandbox) applied to cloud resources
Enrichment context
Business Context Rules — FAQ
How do I prevent suppression rules from becoming permanent blind spots?
Suppression rules require an expiry date unless explicitly marked as permanent. Permanent suppressions require a second approver. All suppressions are listed in a dedicated audit view with age, author, and last-review date.
Can context rules be tested before deploying?
Yes. The context rule sandbox shows which findings from the last 7 days would have been suppressed or escalated by a new rule. You can see the exact findings affected before committing the rule.
What happens if a suppression rule becomes stale after an org change?
Context rules referencing LDAP groups or cloud account IDs are flagged if the referenced object no longer exists. Suppression rules referencing a deleted AWS account trigger an alert to the rule author.
Can context rules affect agent question weights?
Yes. An escalation context rule can increase the weight of the intel_match question in triage agents for entities that match the escalation condition. This ensures that intel hits on PCI assets carry more weight than the same hit on a sandbox.
How do business context rules differ from detection rules?
Detection rules identify suspicious events and produce findings. Business context rules modify how findings are processed — suppressing known-good patterns, escalating critical-asset findings, and encoding organisational risk context such as which accounts are privileged or which environments are PCI-scoped.
Can context rules reference data from external systems like an HR feed or CMDB?
Yes. External attributes can be synchronised into ManySignal entity tags via the entity enrichment API or a scheduled connector. Once an entity has an HR-sourced tag (e.g., on_leave, contractor, terminated), context rules can reference that tag directly.
How many context rules can a tenant have?
There is no hard limit. Performance is a practical consideration for suppression rules that run against every finding — the rule engine processes them sequentially. Teams with large rule sets (500+) are encouraged to use tag-based conditions rather than per-entity conditions to keep evaluation time bounded.
Are context rules version-controlled like detection rules?
Yes. Context rules participate in the detection-as-code Git workflow alongside detection rules. Changes go through the same PR review and CI validation pipeline. Rule diffs are visible in pull requests and the platform change log.
How does ManySignal handle false-positive suppression without introducing compliance risk?
Every suppression rule requires an expiry, an author, and a documented rationale. Suppressed findings are not deleted — they are stored with the suppression reason attached. Compliance reporters can see all suppressed findings and the rules that suppressed them, ensuring suppressions don't hide events from auditors.
Teach the platform what is normal for you
Business context rules ship suppressions, escalations, and org structure in the same YAML-as-code workflow as detection rules.