# Send Events to Google SecOps - Link: https://www.agilicus.com/anyx-guide/send-events-to-google-secops/ - Published: 2026-09-13T17:20:03+00:00 - Author: Don Bowman 1. [Home](https://www.agilicus.com/) 2. Send Events to Google SecOps # Send Events to Google SecOps Configure Agilicus AnyX to send normalised audit events to Google Security Operations( SecOps), formerly Chronicle, as Unified Data Model (UDM) events. [CONTACT](https://www.agilicus.com/contact-us/) ## 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 sends its events to SecOps as structured UDM data over authenticated HTTPS. Where logs originate in segmented or operational technology networks, nested [Agilicus Connectors](https://www.agilicus.com/anyx-guide/agilicus-connector/) 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](https://www.agilicus.com/anyx-guide/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](https://www.agilicus.com/anyx-guide/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: ```wp-block-code 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. ```wp-block-code 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](https://cloud.google.com/chronicle/docs/reference/ingestion-api) reference. ```wp-block-code # 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. ```wp-block-code 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 Organisation -> Audit Destinations in the left sidebar. 2. Click Add Destination in the top action bar. 3. Choose “Google SecOps” 4. Give the destination a memorable name, and choose which types of events to send. 5. Complete the three instance coordinates: 6. * **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. 7. Paste or upload the complete, unedited text of your service account key into ** Service-account JSON key**. 8. Click Create Destination. 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](https://www.agilicus.com/anyx-guide/send-events-to-microsoft-sentinel/). You can modify the settings or rotate credentials by clicking “Reconfigure” in the Actions menu for the destination. Keep the following operational considerations in mind: * 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, delete the destination. AnyX automatically removes the destination and purges the stored secret. ## 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: ```wp-block-code metadata.vendor_name = "Agilicus" ``` Filter by specific UDM event types: ```wp-block-code metadata.event_type = "NETWORK_HTTP" ``` ```wp-block-code metadata.event_type = "USER_RESOURCE_ACCESS" ``` To isolate a specific native Agilicus log category, query the label array: ```wp-block-code 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](https://cloud.google.com/chronicle/docs/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 ```wp-block-code { "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 Can AnyX forward events to both Google SecOps and Microsoft Sentinel at the same time?Yes. Google SecOps and Microsoft Sentinel forwarding run as independent destinations. You can stream events to both platforms simultaneously, or run either provider independently. Yes. Google SecOps and Microsoft Sentinel forwarding run as independent destinations. You can stream events to both platforms simultaneously, or run either provider independently. [Permalink](https://www.agilicus.com/faq/can-anyx-forward-events-to-both-google-secops-and-microsoft-sentinel-at-the-same-time/) Does Agilicus require interactive browser sign-in to Google?No. Event delivery is server-to-server using service-account credentials. AnyX never requests, requires or stores interactive Google user sessions. No. Event delivery is server-to-server using service-account credentials. AnyX never requests, requires or stores interactive Google user sessions. [Permalink](https://www.agilicus.com/faq/does-agilicus-require-interactive-browser-sign-in-to-google/) How do I decommission Google SecOps forwarding?Open Connectors, click SIEM FORWARDING, switch Enable Google SecOps Forwarding to off and click UPDATE SETTINGS. AnyX terminates the forwarder and deletes the stored credential. You should also delete the service- account key in the Google Cloud console. Open **Connectors**, click **SIEM FORWARDING**, switch **Enable Google SecOps Forwarding** to off and click **UPDATE SETTINGS**. AnyX terminates the forwarder and deletes the stored credential. You should also delete the service-account key in the Google Cloud console. [Permalink](https://www.agilicus.com/faq/how-do-i-decommission-google-secops-forwarding/) How does forwarding scale across multiple Connectors?Cloud-origin events are transmitted once by the Agilicus cloud audit forwarder. Connector-origin events are forwarded directly by the specific Connector recording the activity. You do not need to distribute credentials to individual Connectors; configuration is managed centrally. Cloud-origin events are transmitted once by the Agilicus cloud audit forwarder. Connector-origin events are forwarded directly by the specific Connector recording the activity. You do not need to distribute credentials to individual Connectors; configuration is managed centrally. [Permalink](https://www.agilicus.com/faq/how-does-forwarding-scale-across-multiple-connectors/) Where is the service-account private key stored?The key is stored in the Agilicus credentials service as an encrypted audit-destination secret, protected by strict role-based access control. The key is stored in the Agilicus credentials service as an encrypted audit-destination secret, protected by strict role-based access control. [Permalink](https://www.agilicus.com/faq/where-is-the-service-account-private-key-stored/) Which Google API endpoint does AnyX target?AnyX transmits payloads to the regional ingestion endpoint https://{location}-chronicle.googleapis.com using the events: import method and targeting the parent resource projects/{project}/locations/{location}/ instances/{instance}. AnyX transmits payloads to the regional ingestion endpoint `https://{location}-chronicle. googleapis.com` using the `events:import` method and targeting the parent resource` projects/{project}/locations/{location}/instances/{instance}`. [Permalink](https://www.agilicus.com/faq/which-google-api-endpoint-does-anyx-target/)