# Enterprise Intelligence

**Contextualizing AI Investigations with Organizational Knowledge**

## Overview

Enterprise Intelligence is AR²'s framework for incorporating human expertise and organizational context into AI-driven security investigations. While AR²'s AI agents excel at pattern recognition and rapid analysis, they lack the nuanced understanding of your specific business context, internal policies, and institutional knowledge that human analysts possess.

Enterprise Intelligence bridges this gap by allowing security teams to codify their expertise as structured data that AI agents can query and apply during investigations. This transforms AR² from a generic security platform into an organization-specific defense system that understands your unique environment, risks, and priorities.

## Core Concept

### The Challenge

AI agents investigating security alerts face a fundamental limitation: they lack organizational context. Consider these scenarios:

* IP Address Investigation: Is 10.0.50.15 a critical database server or a test environment? Should it be isolated immediately or can we wait for business hours?
* User Account Alert: Is <john.doe@company.com> a regular employee or the CEO? Does this user routinely access sensitive systems or is this anomalous?
* Process Execution: Is `backup_script.exe` a legitimate IT tool or potential malware? Who approved its deployment?
* Domain Access: Is `analytics.company-internal.com` a sanctioned business tool or a typosquatting phishing domain?

Without Enterprise Intelligence, AI agents must treat every alert generically, leading to:

* False Positives: Legitimate business activity flagged as suspicious
* Inappropriate Responses: Overly aggressive actions disrupting business operations
* Missed Context: Failure to escalate truly critical incidents
* Investigation Inefficiency: Repeated queries about known-good entities

### The Solution

Enterprise Intelligence allows you to define artifact types (IPs, users, processes, domains, etc.) and associate them with contextual metadata that informs AI decision-making. When an agent investigates an alert involving a known artifact, it automatically retrieves and applies this context.

When an alert involves 10.0.50.15, the investigating agent immediately knows:

* This is a high-value target requiring elevated scrutiny
* Isolation requires executive approval
* Maintenance windows exist where unusual activity is expected
* The system contains sensitive data, escalating breach impact

## Supported Artifact Types

{% stepper %}
{% step %}

### IP Addresses

Use Cases:

* Identify critical infrastructure (servers, databases, network devices)
* Distinguish internal vs. external IPs
* Define approved external services (cloud providers, SaaS vendors)
* Mark known-malicious IPs for automatic blocking

Contextual Attributes:

| Attribute               | Description                    | Example Values                                          |
| ----------------------- | ------------------------------ | ------------------------------------------------------- |
| **Asset Type**          | Category of system             | Server, Workstation, Network Device, IoT, Cloud Service |
| **Criticality**         | Business impact if compromised | Critical, High, Medium, Low                             |
| **Business Owner**      | Department or team responsible | Finance, HR, Engineering, IT                            |
| **Data Classification** | Sensitivity of data processed  | Public, Internal, Confidential, Restricted              |
| **Approved Services**   | Expected network services      | HTTP (80), HTTPS (443), SSH (22), RDP (3389)            |
| **Geographic Location** | Physical or cloud region       | US-East, EU-West, On-Premises DC1                       |
| **Maintenance Windows** | Scheduled maintenance periods  | Saturday 2-6 AM, First Sunday of month                  |
| **Response Policy**     | Automated action constraints   | Auto-isolate, Require approval, Monitor only            |
| **Known Baselines**     | Normal behavior patterns       | Typical traffic volume, common connections              |

Example Scenarios:

Scenario 1: Critical Database Server

```yaml
IP: 10.0.50.15
Asset Type: Database Server
Criticality: Critical
Business Owner: Finance
Data Classification: PII + Financial
Response Policy: Isolate only with CFO approval
Maintenance Window: Saturday 2-6 AM
```

Agent Behavior:

* Escalates immediately to Tier 3 analysts
* Notifies Finance team and CFO
* Does NOT auto-isolate (requires approval)
* Checks if activity occurs during maintenance window
* Prioritizes investigation over lower-criticality alerts

Scenario 2: Known Cloud Service

```yaml
IP: 52.84.123.45
Asset Type: Cloud Service (AWS CloudFront)
Criticality: Low
Business Owner: IT
Data Classification: Public
Response Policy: Monitor only
```

Agent Behavior:

* Recognizes as approved cloud service
* Does not flag connections as suspicious
* Reduces false positive rate
* Focuses investigation efforts on unknown IPs
  {% endstep %}

{% step %}

### User Accounts

Use Cases:

* Identify privileged users (executives, admins, service accounts)
* Define normal working hours and locations
* Establish baseline behavior patterns
* Specify escalation contacts

Contextual Attributes:

| Attribute             | Description                 | Example Values                                          |
| --------------------- | --------------------------- | ------------------------------------------------------- |
| **User Type**         | Category of account         | Employee, Contractor, Service Account, Admin, Executive |
| **Department**        | Organizational unit         | Engineering, Sales, Finance, HR, IT                     |
| **Job Role**          | Specific function           | Software Engineer, Sales Manager, DBA, CISO             |
| **Privilege Level**   | Access rights               | Standard User, Power User, Administrator, Domain Admin  |
| **Manager**           | Direct supervisor           | <jane.smith@company.com>                                |
| **Working Hours**     | Normal work schedule        | Mon-Fri 9 AM - 6 PM EST                                 |
| **Typical Locations** | Expected geographic access  | New York Office, Home (Brooklyn), AWS US-East           |
| **Approved Systems**  | Systems user should access  | Salesforce, Jira, GitHub, AWS Console                   |
| **Sensitivity**       | Impact if compromised       | High (executive), Medium (employee), Low (contractor)   |
| **MFA Status**        | Multi-factor authentication | Enforced, Optional, Disabled                            |
| **Onboarding Date**   | Account creation date       | 2020-03-15                                              |
| **Offboarding Date**  | Account termination date    | 2024-06-30 (if applicable)                              |

Example Scenarios:

Scenario 1: CEO Account

```yaml
User: ceo@company.com
User Type: Executive
Department: Executive Leadership
Job Role: Chief Executive Officer
Privilege Level: Standard User (by policy)
Sensitivity: Critical
Working Hours: Mon-Fri 8 AM - 7 PM EST
Typical Locations: NYC Office, Home (Manhattan), Frequent travel
MFA Status: Enforced (hardware token)
```

Agent Behavior:

* Any suspicious activity triggers immediate escalation
* Impossible travel alerts prioritized
* Failed MFA attempts escalate to CISO
* Account compromise triggers executive notification protocol
* Considers frequent travel when evaluating location anomalies

Scenario 2: Service Account

```yaml
User: svc_backup@company.com
User Type: Service Account
Department: IT Operations
Job Role: Backup Service
Privilege Level: Administrator (limited scope)
Sensitivity: High
Working Hours: 24/7 (automated)
Approved Systems: Backup servers, Storage arrays, Database servers
Expected Behavior: Nightly backups 2-4 AM, Weekly full backups Sunday
```

Agent Behavior:

* Recognizes automated activity as normal
* Alerts if account used interactively (service accounts shouldn't have interactive logins)
* Flags access outside approved systems
* Monitors for privilege escalation attempts
* Validates activity aligns with backup schedules
  {% endstep %}

{% step %}

### Email Addresses

Use Cases:

* Identify executive email addresses for BEC protection
* Mark approved external partners and vendors
* Define internal vs. external domains
* Track known phishing domains

Contextual Attributes:

| Attribute              | Description                      | Example Values                                    |
| ---------------------- | -------------------------------- | ------------------------------------------------- |
| **Domain Type**        | Email domain category            | Internal, Partner, Vendor, Public, Suspicious     |
| **User Association**   | Linked user account              | <john.doe@company.com> → john.doe (AD account)    |
| **Sensitivity**        | Target value for attackers       | Critical (executive), High (finance), Medium, Low |
| **Approved Senders**   | Whitelisted external senders     | <vendors@partner.com>, <noreply@salesforce.com>   |
| **Blocked Senders**    | Known malicious senders          | <phishing@evil.com>                               |
| **Impersonation Risk** | Likelihood of being impersonated | High (CEO, CFO), Medium, Low                      |

Example Scenarios:

Scenario 1: CFO Email

```yaml
Email: cfo@company.com
Domain Type: Internal
User Association: jane.smith (AD account)
Sensitivity: Critical
Impersonation Risk: High
```

Agent Behavior:

* Monitors for impersonation attempts (lookalike domains)
* Flags wire transfer requests for additional verification
* Alerts on unusual sending patterns
* Escalates BEC (Business Email Compromise) indicators immediately

Scenario 2: Approved Vendor

```yaml
Email: invoices@vendor.com
Domain Type: Vendor (Approved)
Sensitivity: Low
Approved Senders: invoices@vendor.com, support@vendor.com
```

Agent Behavior:

* Recognizes as legitimate vendor
* Does not flag emails as suspicious
* Alerts if email deviates from normal patterns (e.g., unexpected attachments)
  {% endstep %}

{% step %}

### Processes / Executables

Use Cases:

* Whitelist approved IT tools and scripts
* Identify critical business applications
* Flag unauthorized software
* Track software deployment approvals

Contextual Attributes:

| Attribute              | Description                | Example Values                                        |
| ---------------------- | -------------------------- | ----------------------------------------------------- |
| **Process Type**       | Category of executable     | Business Application, IT Tool, System Process, Script |
| **Approval Status**    | Deployment authorization   | Approved, Pending, Unauthorized, Deprecated           |
| **Approved By**        | Authorizing party          | IT Security, Change Management Board                  |
| **Deployment Date**    | When software was deployed | 2023-05-15                                            |
| **Expected Locations** | Where process should run   | C:\Program Files\App\\, /usr/local/bin/               |
| **Digital Signature**  | Code signing certificate   | Verified (Company CA), Verified (Vendor), Unsigned    |
| **Network Behavior**   | Expected network activity  | No network access, HTTPS to api.service.com only      |
| **Parent Processes**   | Expected execution chain   | explorer.exe, cmd.exe, scheduled\_task.exe            |

Example Scenarios:

Scenario 1: Approved IT Tool

```yaml
Process: backup_agent.exe
Process Type: IT Tool
Approval Status: Approved
Approved By: IT Security (Ticket #12345)
Deployment Date: 2023-08-01
Expected Locations: C:\\Program Files\\BackupSoft\\
Digital Signature: Verified (BackupSoft Inc.)
Network Behavior: HTTPS to backup.company.com only
```

Agent Behavior:

* Recognizes as legitimate tool
* Does not flag execution as suspicious
* Alerts if executed from unexpected location
* Flags if network behavior deviates (e.g., connects to unknown domains)

Scenario 2: Unauthorized Process

```yaml
Process: cryptominer.exe
Process Type: Unauthorized Software
Approval Status: Blocked
Approved By: N/A
```

Agent Behavior:

* Immediately flags execution as malicious
* Auto-terminates process (if policy allows)
* Isolates affected endpoint
* Escalates to security team
  {% endstep %}

{% step %}

### URLs / Domains

Use Cases:

* Whitelist approved SaaS applications
* Identify internal domains and subdomains
* Flag typosquatting and phishing domains
* Track approved external services

Contextual Attributes:

| Attribute               | Description                  | Example Values                                        |
| ----------------------- | ---------------------------- | ----------------------------------------------------- |
| **Domain Type**         | Category of domain           | Internal, SaaS (Approved), Partner, Public, Malicious |
| **Business Purpose**    | Why domain is accessed       | CRM, Email, Collaboration, Analytics, Marketing       |
| **Approval Status**     | Authorization status         | Approved, Pending Review, Blocked                     |
| **Data Classification** | Sensitivity of data sent     | Public, Internal, Confidential, Restricted            |
| **Expected Users**      | Who should access            | All employees, Sales team only, IT admins only        |
| **SSL Certificate**     | Expected certificate details | Issued by DigiCert, Valid until 2025-12-31            |

Example Scenarios:

Scenario 1: Approved SaaS Application

```yaml
Domain: app.salesforce.com
Domain Type: SaaS (Approved)
Business Purpose: CRM
Approval Status: Approved
Data Classification: Confidential (customer data)
Expected Users: Sales, Marketing, Support teams
```

Agent Behavior:

* Recognizes as approved business tool
* Does not flag access as suspicious
* Monitors for unusual data exfiltration patterns
* Alerts if accessed by unauthorized departments

Scenario 2: Typosquatting Domain

```yaml
Domain: app.salesf0rce.com  # Note: "0" instead of "o"
Domain Type: Malicious (Typosquatting)
Approval Status: Blocked
```

Agent Behavior:

* Immediately flags as phishing attempt
* Blocks access at firewall/proxy
* Alerts security team
* Identifies affected users for remediation
  {% endstep %}

{% step %}

### File Hashes

Use Cases:

* Whitelist approved software and scripts
* Track known-malicious files
* Identify custom internal tools
* Monitor file deployment and propagation

Contextual Attributes:

| Attribute             | Description              | Example Values                                    |
| --------------------- | ------------------------ | ------------------------------------------------- |
| **File Type**         | Category of file         | Executable, Script, Document, Archive, Library    |
| **Approval Status**   | Authorization status     | Approved, Quarantined, Blocked, Unknown           |
| **Source**            | Origin of file           | Internal Development, Vendor, Public Download     |
| **Digital Signature** | Code signing status      | Signed (Company), Signed (Vendor), Unsigned       |
| **Deployment Scope**  | Where file should exist  | IT workstations only, All endpoints, Servers only |
| **First Seen**        | When file first observed | 2024-01-15                                        |
| **Reputation**        | Known good/bad status    | Known Good, Suspicious, Known Malicious           |
| {% endstep %}         |                          |                                                   |

{% step %}

### Registry Keys (Windows)

Use Cases:

* Monitor critical system configuration
* Track approved registry modifications
* Detect persistence mechanisms
* Identify unauthorized changes

Contextual Attributes:

| Attribute               | Description             | Example Values                                     |
| ----------------------- | ----------------------- | -------------------------------------------------- |
| **Registry Path**       | Full registry key path  | HKLM\Software\Company\AppName                      |
| **Purpose**             | Why registry key exists | Application configuration, System setting          |
| **Approval Status**     | Authorization status    | Approved, Unauthorized                             |
| **Expected Value**      | Normal value or range   | "EnableFeature"=1, "Version"="2.5.0"               |
| **Modification Policy** | Who can change          | IT Admins only, Application installer, System only |
| {% endstep %}           |                         |                                                    |

{% step %}

### Groups / Organizational Units

Use Cases:

* Define privileged groups (Domain Admins, Executives)
* Establish group membership baselines
* Track group modification approvals
* Identify sensitive organizational units

Contextual Attributes:

| Attribute             | Description           | Example Values                                           |
| --------------------- | --------------------- | -------------------------------------------------------- |
| **Group Type**        | Category of group     | Security Group, Distribution List, AD Group, Cloud Group |
| **Privilege Level**   | Access rights granted | Standard, Elevated, Administrative, Executive            |
| **Business Purpose**  | Why group exists      | Access control, Email distribution, Resource sharing     |
| **Membership Policy** | Who can join          | Manager approval, IT approval, Self-service              |
| **Audit Frequency**   | Review schedule       | Weekly, Monthly, Quarterly                               |
| **Sensitivity**       | Impact if compromised | Critical, High, Medium, Low                              |

Example Scenario: Domain Admins Group

```yaml
Group: Domain Admins
Group Type: Security Group (Active Directory)
Privilege Level: Administrative
Business Purpose: Full domain control
Membership Policy: CISO approval required
Audit Frequency: Weekly
Sensitivity: Critical
Expected Members: 3-5 IT administrators
```

Agent Behavior:

* Alerts on any membership changes immediately
* Escalates to CISO for approval verification
* Monitors member activity for privilege abuse
* Flags if membership count exceeds expected range
  {% endstep %}

{% step %}

### Certificates

Use Cases:

* Track approved SSL/TLS certificates
* Monitor certificate expiration
* Identify rogue certificates
* Validate certificate authorities

Contextual Attributes:

| Attribute            | Description              | Example Values                              |
| -------------------- | ------------------------ | ------------------------------------------- |
| **Certificate Type** | Category of certificate  | SSL/TLS, Code Signing, Email, Client Auth   |
| **Issuer**           | Certificate authority    | DigiCert, Let's Encrypt, Internal CA        |
| **Subject**          | Certificate owner        | \*.company.com, app.company.com             |
| **Expiration Date**  | When certificate expires | 2025-12-31                                  |
| **Approval Status**  | Authorization status     | Approved, Pending, Revoked                  |
| **Business Purpose** | Why certificate exists   | Public website, Internal API, Email signing |
| {% endstep %}        |                          |                                             |

{% step %}

### Cloud Resources

Use Cases:

* Identify critical cloud infrastructure
* Track approved cloud services
* Monitor resource configurations
* Define cloud security policies

Contextual Attributes:

| Attribute                   | Description                | Example Values                                         |
| --------------------------- | -------------------------- | ------------------------------------------------------ |
| **Resource Type**           | Category of cloud resource | EC2 Instance, S3 Bucket, Lambda Function, RDS Database |
| **Cloud Provider**          | Hosting provider           | AWS, Azure, GCP, Oracle Cloud                          |
| **Environment**             | Deployment stage           | Production, Staging, Development, Test                 |
| **Criticality**             | Business impact            | Critical, High, Medium, Low                            |
| **Data Classification**     | Sensitivity of data        | Public, Internal, Confidential, Restricted             |
| **Business Owner**          | Responsible team           | Engineering, DevOps, Data Science                      |
| **Approved Configurations** | Expected settings          | Encryption enabled, Public access disabled             |
| {% endstep %}               |                            |                                                        |
| {% endstepper %}            |                            |                                                        |

## Enterprise Intelligence Workflow

### Data Collection

Enterprise Intelligence data can be populated through multiple methods:

Manual Entry:

* Web UI for ad-hoc additions

Automated Discovery:

* Integration with CMDB (Configuration Management Database)
* Sync with Active Directory / Azure AD
* Import from asset management systems
* Discovery from SIEM and EDR platforms

Continuous Updates:

* Scheduled sync with authoritative sources
* Real-time updates via API integrations
* Analyst feedback during investigations

### Agent Utilization

During investigations, AI agents automatically query Enterprise Intelligence.

{% stepper %}
{% step %}

### Investigation Flow

Alert Received

* Agent receives security alert (e.g., "Suspicious process execution on 10.0.50.15")
  {% endstep %}

{% step %}
Artifact Extraction

* Agent identifies artifacts in alert (IP: 10.0.50.15, Process: backup\_agent.exe)
  {% endstep %}

{% step %}
Context Retrieval

* Agent queries Enterprise Intelligence for each artifact
  {% endstep %}

{% step %}
Context Application

* Agent applies context to investigation:
  * 10.0.50.15 is a critical database server (escalate priority)
  * backup\_agent.exe is approved IT tool (reduce suspicion)
  * Activity during maintenance window (expected behavior)
    {% endstep %}

{% step %}
Decision Making

* Agent determines appropriate response based on context
  {% endstep %}

{% step %}
Action Execution

* Agent executes response (e.g., monitor only, no isolation needed)
  {% endstep %}
  {% endstepper %}

### Feedback Loop

Enterprise Intelligence improves over time through analyst feedback.

Learning Mechanisms:

* False Positive Feedback: Analyst marks alert as false positive → Agent suggests adding artifact to Enterprise Intelligence
* Investigation Insights: Analyst discovers new context during investigation → Agent prompts to update Enterprise Intelligence
* Pattern Recognition: Agent identifies recurring artifacts without context → Agent recommends adding to Enterprise Intelligence
* Continuous Refinement: Regular reviews of Enterprise Intelligence data for accuracy and completeness

## Configuration and Management

### Web UI

Enterprise Intelligence Dashboard:

* View all artifacts by type
* Search and filter artifacts
* Add/edit/delete artifacts
* Bulk import via CSV
* Export for backup/audit

Artifact Detail View:

* Full context attributes
* Investigation history (how many times artifact appeared in alerts)
* Last updated timestamp and user
* Related artifacts (e.g., user → email → IP)

## Best Practices

### Start with High-Value Artifacts

Priority Order:

1. Executives and Privileged Users: Highest impact if compromised
2. Critical Infrastructure: Database servers, domain controllers, payment systems
3. Approved IT Tools: Reduce false positives from legitimate admin activity
4. Known-Malicious Indicators: IPs, domains, file hashes from threat intelligence

### Maintain Data Quality

Quality Principles:

* Accuracy: Ensure context attributes are correct and up-to-date
* Completeness: Provide as much context as available (more context = better decisions)
* Timeliness: Update Enterprise Intelligence when changes occur (e.g., user role changes)
* Consistency: Use standardized values (e.g., "Critical" not "High Priority")

### Automate Where Possible

Automation Opportunities:

* CMDB Sync: Automatically import asset data from configuration management database
* AD/Azure AD Sync: Keep user context synchronized with identity providers
* SIEM Integration: Import known-good artifacts from SIEM correlation rules
* Threat Intelligence Feeds: Automatically add known-malicious indicators

### Regular Reviews

Review Schedule:

* Weekly: High-value artifacts (executives, critical infrastructure)
* Monthly: Medium-value artifacts (general users, standard servers)
* Quarterly: Low-value artifacts (test systems, decommissioned assets)
* Ad-Hoc: After major organizational changes (acquisitions, restructuring)

### Leverage Investigation Feedback

Feedback Integration:

* Analysts can suggest Enterprise Intelligence updates directly from investigation UI
* AR² tracks which artifacts appear frequently without context (candidates for addition)
* Automated prompts when agents encounter unknown artifacts repeatedly

***

## Impact on Investigation Quality

Before Enterprise Intelligence

Generic Investigation:

* Alert: "Suspicious process execution on 10.0.50.15"
* Agent Analysis: Unknown IP, unknown process, recommend isolation
* Result: False positive, legitimate backup process on production database server
* Business Impact: Database outage, revenue loss, analyst time wasted

After Enterprise Intelligence

Context-Aware Investigation:

* Alert: "Suspicious process execution on 10.0.50.15"
* Agent Analysis:
  * IP 10.0.50.15 = Critical database server (Finance)
  * Process = backup\_agent.exe (Approved IT tool)
  * Time = Saturday 3:15 AM (within maintenance window)
  * Conclusion: Expected behavior, no action needed
* Result: True negative, no disruption
* Business Impact: Zero downtime, analyst time saved

Measurable Improvements:

| Metric                   | Before Enterprise Intelligence | After Enterprise Intelligence | Improvement     |
| ------------------------ | ------------------------------ | ----------------------------- | --------------- |
| **False Positive Rate**  | 40%                            | 15%                           | 62% reduction   |
| **Investigation Time**   | 45 minutes avg                 | 30 minutes avg                | 33% faster      |
| **Escalation Accuracy**  | 60%                            | 90%                           | 50% improvement |
| **Business Disruption**  | 5 incidents/month              | 0.5 incidents/month           | 90% reduction   |
| **Analyst Satisfaction** | 6/10                           | 9/10                          | 50% improvement |

## Security and Privacy Considerations

### Data Sensitivity

Enterprise Intelligence may contain sensitive organizational information:

* Employee names, roles, and contact information
* Critical infrastructure details
* Business processes and workflows
* Security policies and procedures

Protection Measures:

* Encryption: All Enterprise Intelligence data encrypted at rest and in transit
* Access Control: Role-based access control limits who can view/edit artifacts
* Audit Logging: All changes logged with user, timestamp, and reason
* Data Minimization: Only collect context necessary for investigations

### Compliance

Enterprise Intelligence supports compliance requirements:

* GDPR: Data retention policies, right to erasure, data minimization
* SOC 2: Access controls, audit logging, change management
* ISO 27001: Asset inventory, risk classification, access control

## Getting Started

{% stepper %}
{% step %}

### Phase 1: Initial Setup (Week 1)

Objectives:

* Import high-value artifacts
* Configure automated sync
* Train security team

Tasks:

1. Identify 50-100 high-value artifacts (executives, critical servers, approved tools)
2. Prepare CSV import file
3. Import via Web UI
4. Configure CMDB/AD sync (if available)
5. Conduct training session for analysts
   {% endstep %}

{% step %}

### Phase 2: Expansion (Weeks 2-4)

Objectives:

* Expand artifact coverage
* Refine context attributes
* Measure impact

Tasks:

1. Import medium-value artifacts (general users, standard servers)
2. Review investigation feedback for missing context
3. Add artifacts suggested by agents
4. Measure false positive reduction
5. Adjust context attributes based on investigation outcomes
   {% endstep %}

{% step %}

### Phase 3: Optimization (Ongoing)

Objectives:

* Maintain data quality
* Automate updates
* Continuous improvement

Tasks:

1. Schedule regular reviews (weekly/monthly/quarterly)
2. Implement automated sync for all available sources
3. Monitor Enterprise Intelligence usage metrics
4. Solicit analyst feedback
5. Expand artifact types as needed
   {% endstep %}
   {% endstepper %}

## Conclusion

Enterprise Intelligence transforms AR² from a generic AI security platform into an organization-specific defense system that understands your unique environment, risks, and priorities. By codifying human expertise as structured data, you enable AI agents to make context-aware decisions that balance security effectiveness with business continuity.

Organizations that invest in comprehensive Enterprise Intelligence see dramatic reductions in false positives, faster investigation times, and higher analyst satisfaction. The initial setup effort pays dividends through improved investigation quality and reduced operational overhead.

For Enterprise Intelligence setup assistance, best practices consulting, or integration support, contact <solutions@blusapphire.com>

Document Version: 1.0\
Last Updated: February 2026\
Next Review: May 2026


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.blusapphire.io/release-6.0/04_ar2-agentic-ai/enterprise-intelligence.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.