bbyoc anywhere
VIII
commandment VIII

Every Action Leaves Two Trails

Record intent in your agent's audit stream and fact in the cloud's own log, and join the two so the customer can verify every action against a record you cannot edit.

 two trails, one truth: joinable, deliverable, unsuppressable
INSIDE THE CUSTOMER ACCOUNTagent actione.g. scale node poolaudit event: intentprincipal · tenant · requestcloud request-id embeddedemitted for every actionthe cloud's own audit logCloudTrail · Activity Logcannot be suppressedwritten by the cloud itselfcloud API callsdedicated role · tagged sessions⋈ join on request-idOTel CollectorSIEM / securitySplunk · Sentinel ·Chronicle · Elasticcloud-native auditCloudTrail Lake ·Security Lake · OCSFWORM archiveS3 Object Lock ·retention lockthe SOC's pipeline, no custom glueTHE FIVE QUESTIONS THIS ANSWERSattributioncompletenesstamper evidencecorrelationdeliveryverify the vendor's story against a record the vendor cannot edit

When an enterprise security team evaluates letting your agent run in their account, expect five questions. 1. Attribution: which principal did what, on whose behalf, triggered by which control-plane request? 2. Completeness: can you prove no events were dropped or suppressed? 3. Tamper evidence: could a compromised agent rewrite its own trail? 4. Correlation: can the customer join your events against their cloud-native audit logs? 5. Delivery: will events land in their SOC's existing pipeline without custom glue? Design your audit architecture as direct answers to those five questions.

BYOC gives you a structural answer here that pure SaaS cannot offer. Because your agent acts through IAM roles inside the customer's account (Commandment IV), every cloud API call it makes already lands in the customer's Cloud Audit Logs: infrastructure the customer already trusts, on a write path neither your agent nor your control plane can touch. The cloud provider supplies tamper evidence and completeness for this ground-truth record. A compromised agent can go silent, and it still holds no way to erase what the cloud has already recorded.

Raw API events record what happened. Your agent's own audit stream supplies the intent layer over that ground truth: every event carries the acting principal, the tenant, and the control-plane request that triggered it. Your control plane must stamp a unique request ID on every command it issues, and your agent must propagate that ID into every event it emits. Give the agent dedicated roles with distinctive session names and tags so its calls are instantly filterable in the cloud's log, and embed the cloud request IDs in your audit events so the two trails join row by row. That join is the differentiator: the customer can verify your story against a record you cannot edit. It also proves completeness, because a gap in the intent trail with no matching gap in the cloud log is immediately visible.

Events stranded in a vendor console fail the fifth question. Deliver to the SOC's existing tooling: OTLP through an OpenTelemetry Collector reaches effectively the entire enterprise estate (Splunk, Sentinel, Chronicle, Elastic, QRadar, Datadog, and the Kafka and Cribl pipelines behind them) with no per-SIEM glue. An OCSF-aligned schema makes ingestion into AWS Security Lake nearly free, and two small native sinks cover the remainder: CloudTrail Lake for cloud-native audit, and object storage with retention lock (S3 Object Lock) for a WORM compliance archive that makes immutability a verifiable property of the storage layer. All of these sinks live in the customer's account. Your control plane may keep its own history of the commands it issued, and it must never be the sole home of the trail.