List Audit trail configs

When Truto actually read this object from the provider, in UTC ISO 8601 with the offset present. Not when the request was made and not a provider timestamp. Drives consumer staleness rules.

The provider's own identifier for the trail or logging configuration.

Whether the configuration captures every region rather than one. A trail covering one region while the customer's workloads run in another manufactures false assurance.

Whether the configuration applies across the organisation rather than a single account.

Whether the trail is actually recording. Not readable from the trail description on AWS: a trail can exist, be multi-region, encrypted and validated, and be completely stopped, and the description looks identical either way. This requires a separate per-trail status call, which is not optional.

Truto's stable unified identifier for this object. Opaque; use provider_ref to address the object in the provider's own console or API.

The provider's own type string, unmodified -- for example 'AWS::S3::Bucket', 'aws_iam_role', 'Microsoft.Sql/servers'. Used for display and drill-down.

Which cloud this object was read from.

The provider's own unbroken identifier, passed through verbatim -- a full ARN, resource id or self-link. Never truncated, prefixed or normalised. This is the customer-facing key used to find the object in the console.

The provider reference for the scope.

The level the configuration applies at.

Which audit mechanism this row describes. Carried because an account's only audit configuration may not be a classic trail at all, and a trails-only scan would wrongly report that account as unaudited.

How confident Truto is in data_access_logging_by_service. Declared rather than implied, because an allowlist of a few resource types silently under-reports a predicate that matches more.

Per-service data-plane logging coverage, as objects carrying the service, the resource type, whether reads and writes are logged and the selector that produced the answer. The field the brief names as most likely to be dropped, and it answers 'are the logs that show who READ data switched on', which is off by default on some providers. Best-effort inference where the provider uses a predicate language: negation can carve arbitrary holes out of a broad match, no API evaluates the predicate, and the confidence is declared rather than implied.

Which selector dialect produced data_access_logging_by_service. The two dialects are mutually exclusive and need different parsers; the simple one enumerates resource types explicitly, the advanced one is a boolean predicate language that cannot be fully resolved offline.

Where the audit records are delivered.

What kind of destination that is, as the provider names it.

The customer-managed key protecting the audit records. An absent value means provider-side encryption, NOT unencrypted -- reporting a missing key reference as 'logs are not encrypted' is a false finding.

Management event sources deliberately carved out of the trail, commonly for cost. Coverage is not complete even when management events are nominally included, and this field is what makes that visible.

The provider's raw logging flag, kept beside enabled. Note that true is still not proof logs arrive: a trail writing to a deleted destination reports true with a stale delivery timestamp, so the provider's latest delivery error and delivery time are checked before enabled is reported true; both remain available in remote_data.

Which categories of event are recorded, as the provider names them.

The provider's own integrity validation flag, carried separately.

Whether control-plane events are recorded. Not the whole answer on its own -- see excluded_management_event_sources.

Where the object is. A compliance answer in its own right, not metadata. The literal string 'global' is emitted for genuinely global resources (for example IAM, or a GCP VPC network) rather than guessing a region. Never invented: where the provider does not return a location and none can be derived, the collector's queried region is used and that substitution is recorded in unreadable_fields.

Raw data returned from the remote API call.

Key-value pairs exactly as the customer set them: no case folding, no key or value normalisation, no merging of separate provider concepts. Present on every object because tags are the primary input for environment classification. An empty object means the object carries no tags; tags that could not be read are recorded in unreadable_fields instead.

Whether the trail is cryptographically protected against alteration. Deliberately not merged with deletion protection: preventing deletion does not prove non-alteration, and conflating them misleads an auditor.

Per-object list of the fields that could not be read, and why -- the brief section 8.4 answer, chosen over per-field sentinel values. Each entry is an object with 'field' (the property name on this resource), 'reason' (a reason code) and an optional human-readable 'detail'. Reason codes: not_supported_by_provider, not_configured, permission_denied, not_collected, collection_error, partially_collected. An empty array means every property on this object was read successfully. A property absent from this array and null in the payload means the provider genuinely returned no value, which is different from 'we could not look'.