How Agilicus delivers to Google SecOps

Agilicus AnyX records audit events for authentication, authorisation, access and Application Programming Interface (API) activity, and can deliver them to any number of destinations. Google Security Operations (SecOps) is one such destination. Rather than requiring Google SecOps to parse a proprietary or legacy format, AnyX translates each event into Google’s Unified Data Model (UDM) before it leaves the platform, then delivers it directly using the Chronicle API events:import method.

This matters because Google SecOps does not ingest raw syslog, and unencrypted syslog over UDP port 514 should never be routed to the internet. AnyX consumes legacy log sources locally, normalises them, and forwards them as structured UDM data over authenticated HTTPS. Where logs originate in segmented or operational technology networks, nested Agilicus Connectors chain outbound-only tunnels so that records climb from lower network levels to the cloud without punching holes in internal firewalls.

Users sign in with their existing corporate identity rather than a shadow account. Access is authorised per resource rather than all-or-nothing, and users reach resources without a virtual private network (VPN) or inbound port forwarding.

There are two delivery paths, and both operate automatically once the destination is enabled:

• Cloud-origin events (for example, administrative activity recorded by the Agilicus cloud) are delivered by the Agilicus cloud audit forwarder.
• Connector-origin events (for example, resource access recorded on premises) are delivered by the Agilicus Connector over its outbound-only connection. No inbound firewall rule is required.

Both delivery paths use the same audit destination configuration, the same service-account credential and the same UDM normalisation engine.

Before you begin

Ensure you have the following prerequisites in place before starting configuration:

Google Cloud requirements

• A Google SecOps instance. You will need its Google Cloud project ID, its location (such as us or europe) and its instance ID.
• Administrative permissions in that Google Cloud project to create a service account and bind an Identity and Access Management role.
• Permission to generate and download a JSON private key for that service account.

Agilicus AnyX requirements

• An organisation administrator account in the Agilicus admin portal with permissions to manage audit destinations.
• The Google SecOps forwarding feature enabled for your organisation licence.

Network connectivity

• Outbound HTTPS (TCP port 443) from the Agilicus cloud to {location}-chronicle.googleapis.com and oauth2.googleapis.com.
• For on-premises sources, standard outbound-only connectivity from your Agilicus Connector. You never open any inbound firewall port.

Set up Google Cloud

Setting up Google Cloud requires gathering your instance coordinates, creating a dedicated service account, granting least-privilege ingestion rights and generating a JSON key.

Confirm the instance coordinates

In the Google SecOps console, locate your instance and record its project ID, location and instance ID. These three components form the instance resource hierarchy in the Google Cloud Platform (GCP) ingestion API:

projects/{project}/locations/{location}/instances/{instance}

The location is a Google Cloud region or multi-region such as us or europe. You will enter these values into the Agilicus portal.

Create a service account

Create a dedicated service account for Agilicus log ingestion. Using a dedicated identity ensures clean audit separation and simplifies credential rotation.

gcloud iam service-accounts create agilicus-secops-ingest \
  --project PROJECT_ID \
  --display-name "Agilicus SecOps ingestion"

Grant the ingestion permission

Grant the service account permission to import events. The principle of least privilege dictates creating a custom role that contains solely the chronicle.events.import permission as documented in the Google SecOps ingestion API reference.

# Least privilege: create a custom role containing only chronicle.events.import
gcloud iam roles create agilicusSecopsIngest \
  --project PROJECT_ID \
  --permissions chronicle.events.import

# Bind the custom role to the service account
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member "serviceAccount:agilicus-secops-ingest@PROJECT_ID.iam.gserviceaccount.com" \
  --role projects/PROJECT_ID/roles/agilicusSecopsIngest

Agilicus requests only the narrow https://www.googleapis.com/auth/chronicle OAuth scope rather than wide cloud-platform scopes. If organisational policy mandates predefined roles, you can substitute roles/chronicle.editor, though the custom role is strongly recommended.

Create a service-account JSON key

Generate a private key file for the service account and download it. Treat this key file as a sensitive credential.

gcloud iam service-accounts keys create secops-key.json \
  --iam-account agilicus-secops-ingest@PROJECT_ID.iam.gserviceaccount.com

You will paste the full JSON contents of this file into the Agilicus portal in the next step.

Configure Agilicus AnyX

With the Google Cloud service account established, configure event forwarding in the Agilicus administrative portal:

1. Sign in to the Agilicus admin portal and navigate to Connectors in the left sidebar.
2. Click SIEM FORWARDING in the top action bar.
3. Enable the toggle labelled Enable Google SecOps Forwarding.
4. Complete the three instance coordinates:
   • Google Cloud project ID: the project ID hosting the SecOps instance.
   • GCP location: the regional location code, for example us or europe.
   • Instance ID: your Google SecOps instance identifier.
5. Paste the complete, unedited text of your service account key into Service-account JSON key.
6. Click UPDATE SETTINGS.

AnyX creates an audit destination named Agilicus Google SecOps Forwarding and encrypts the key at rest in the credentials store. The destination is viewable under Organisation → Audit Destinations alongside other destinations such as Microsoft Sentinel. Always use the SIEM FORWARDING interface to modify settings or rotate credentials rather than editing raw destination fields manually.

Keep the following operational considerations in mind:

• The Microsoft Sentinel Proxy toggle in the same dialog operates independently. You can enable both destinations simultaneously or operate either alone.
• When returning to this screen, the key field remains intentionally blank for security. Leave it empty to retain the current active credential, or paste a replacement key to rotate.
• To decommission forwarding, toggle Enable Google SecOps Forwarding to off and click save. AnyX automatically removes the destination and purges the stored secret.
• By default, all audit event categories are forwarded. To restrict forwarded event types, configure filters under Organisation → Audit Destinations. The SIEM FORWARDING interface preserves existing filters during subsequent updates.

Verify events in Google SecOps

Events start arriving shortly after you save settings. Audit destinations do not use synthetic connection tests. Verification is performed by generating genuine system activity and confirming ingestion in the Google SecOps console.

Sign in to the AnyX portal or access an AnyX-protected application, then open Search in Google SecOps to query UDM records. Begin with a baseline vendor query:

metadata.vendor_name = "Agilicus"

Filter by specific UDM event types:

metadata.event_type = "NETWORK_HTTP"

metadata.event_type = "USER_RESOURCE_ACCESS"

To isolate a specific native Agilicus log category, query the label array:

about.labels["log_type"] = "access"

If label filtering returns no matches in your console view, use the SecOps search bar field picker to verify tenant label syntax, or filter by metadata.product_name = "Agilicus" and inspect an event structure directly.

What gets forwarded

Agilicus AnyX maps native audit records directly into Google’s Unified Data Model before egress. The following tables describe the released field translations implemented in the core audit engine.

Log types and event types

Agilicus log type	UDM event_type	Principal	Target
access	NETWORK_HTTP	User ID, user display name, source IP address	Hostname, URL, port, resource name and type
authorization	USER_RESOURCE_ACCESS	User ID, user display name, source IP address	Resource name and type, URL or path
logs (unstructured)	GENERIC_EVENT, or STATUS_UPDATE when severity is present	Hostname	Resource name
Other categories	GENERIC_EVENT	User ID when present	Resource name when present

For access events, HTTP attributes including method, response code, user agent and referral URL map directly into network.http.*. The security_result.action field is assigned ALLOW on successful HTTP responses and BLOCK on errors. For authorization events, security_result.action reflects the explicit allow or deny access decision.

Common metadata

UDM field	Source attribute
metadata.event_timestamp	Event collection timestamp, falling back to event start timestamp
metadata.event_type	Mapped according to the log type table above
metadata.vendor_name	Agilicus
metadata.product_name	Agilicus
metadata.product_log_id	Unique event identifier, used for upstream deduplication
metadata.description	Event message string on unstructured log records
about.labels	Key-value pairs for org, org_name, source_type, source_id, source_org_id, hostname and log_type

Severity mapping

Agilicus level	UDM security_result.severity
trace, debug, info	INFORMATIONAL
warning	MEDIUM
error	ERROR
fatal, panic	CRITICAL
absent	UNKNOWN_SEVERITY

Extensions and unmapped attributes

Attributes without an exact top-level UDM field are preserved within the UDM extensions structure. This retains full query capabilities for operational indicators, including: org, org_name, jti, request_id, session, resource_org_id, target_id, target_name, target_org_id, flags, duration_ms, bytes_sent, bytes_received, authenticated, whitelisted, redirected, forged_response, error and agilicus_extensions.

Example UDM access event

{
  "metadata": {
    "event_timestamp": "2026-09-11T14:22:01.123Z",
    "event_type": "NETWORK_HTTP",
    "vendor_name": "Agilicus",
    "product_name": "Agilicus",
    "product_log_id": "6d2f0a3e-1111-4222-8333-000000000001"
  },
  "principal": {
    "user": {
      "userid": "user@example.com",
      "user_display_name": "User Example"
    },
    "ip": [
      "203.0.113.7"
    ]
  },
  "target": {
    "hostname": "app.example.com",
    "url": "https://app.example.com/reports",
    "port": 443,
    "resource": {
      "name": "Reports",
      "type": "APPLICATION"
    }
  },
  "network": {
    "http": {
      "method": "GET",
      "response_code": 200,
      "user_agent": "Mozilla/5.0"
    }
  },
  "security_result": {
    "action": "ALLOW"
  },
  "about": {
    "labels": [
      {
        "key": "org",
        "value": "acme"
      },
      {
        "key": "source_type",
        "value": "agent-connector"
      },
      {
        "key": "log_type",
        "value": "access"
      }
    ]
  }
}

Batching, retries and reliability

To guarantee dependable delivery without impacting user traffic or overwhelming ingestion quotas, the forwarding subsystem incorporates rigorous transport mechanics:

• Batch size and envelope limits: AnyX buffers records into discrete batches capped at 1 MiB of formatted JSON payload and bounded by maximum event counts. Oversized batches are split automatically before transmission.
• Atomic validation: The Google SecOps ingestion API enforces all-or-nothing batch processing. If one record fails validation, the entire payload is rejected. AnyX performs client-side pre-validation against UDM schemas to prevent rejected batches, alerting administrators if anomalous records occur.
• Resilient retries: Transient network interruptions, server errors (HTTP 5xx) and rate limiting (HTTP 429) trigger exponential backoff, honouring upstream Retry-After headers. Authentication tokens approaching expiration are renewed automatically. Timeouts are set to 30 seconds per request.
• Idempotent deduplication: Every event carries a deterministic metadata.product_log_id. When network partitions cause retransmissions and Google responds that a batch has already been imported, AnyX treats the batch as successfully delivered, preventing data duplication.

Troubleshooting

Symptom	Likely cause	Resolution
No events visible in Google SecOps	No new audit activity generated yet	Sign in to AnyX or access a published resource, then re-run the UDM query.
No events visible in Google SecOps	Service account lacks necessary Identity and Access Management role	Confirm chronicle.events.import is bound to the service account on the target project.
No events visible in Google SecOps	Mismatched instance coordinates	Verify the project ID, location and instance ID match the resource hierarchy in SecOps.
Authentication failures logged	Service account key deleted or revoked	Generate a new JSON key in Google Cloud and paste it into the SIEM forwarding dialog.
Authentication failures logged	Truncated or malformed key contents	Re-paste the entire JSON file contents, confirming opening and closing braces are included.
Batch rejection warnings	Malformed event field failed schema check	The offending batch is flagged and retained rather than dropped. Contact Agilicus support with destination details.
Duplicate batch notices	Harmless retry acknowledgement	Normal operational behaviour during network hiccups. AnyX treats previously ingested batches as delivered.
No events from on-premises sources	Connector disconnected or offline	Check Connector health and connectivity in the Connectors list in the Agilicus portal.

Security and permissions

Log forwarding is architected around strict isolation and least privilege:

• Least privilege access: The integration requires only a dedicated service account assigned a custom role containing solely chronicle.events.import. OAuth authorization is scoped strictly to https://www.googleapis.com/auth/chronicle.
• Zero Trust Architecture: The platform adheres to Zero Trust Architecture principles. User access is authorised per resource rather than granting broad network entrance, eliminating the need for virtual private networks.
• Secure credential storage: Service-account JSON keys are stored as encrypted audit-destination secrets. Keys cannot be read back through the user interface or web APIs.
• Seamless rotation: Keys can be rotated without interruption. Generating a new key in Google Cloud and pasting it into the admin portal replaces the active secret immediately on subsequent deliveries.
• Outbound-only communication: Egress uses standard outbound HTTPS over port 443. Neither the Agilicus cloud nor on-premises Connectors require listening ports or inbound firewall pinholes.
• Unified corporate directory: Because users authenticate against your existing corporate identity provider with multi-factor authentication, revoking a user identity centrally instantly cuts access across all systems and creates an authoritative audit record.

Frequently asked questions