List Managed keys

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.

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 identifier for the key.

The key's cryptographic type, as the provider names it.

Who manages the key. The distinction an auditor asks about, and the reason provider-managed service keys are separated from customer keys rather than counted together.

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's own key state string, verbatim.

Human-readable aliases for the key.

Settings on the vault or key ring that prevent accidental deletion -- purge protection, soft delete, deletion prevention. On some providers these matter more than rotation.

How long the provider waits before destroying a key scheduled for deletion.

The raw key policy document, where it could be read.

The provider's own key specification string, verbatim.

Whether this key is part of a multi-region key set. Carried so that one logical key is not reported as several unrelated keys, and because rotation is a shared property configured only on the primary.

When the key is next due to rotate.

Where the key material came from -- generated in the key service, imported, or held in an external or hardware key store.

Whether the key policy grants use to anyone. A heuristic, not a provider fact: no API answers 'is this key public', and naive wildcard-principal matching produces false positives on every normal key, because the standard idiom pairs a wildcard principal with a condition scoping it to the owning account. Determined by the ABSENCE of a scoping condition. Note also that the key policy is not the only authorization path -- grants are a second, independent one -- and that the policy cannot be read cross-account at all, so this is commonly permission_denied.

The condition keys found scoping the key policy, so the consumer can audit Truto's public-key heuristic rather than trust it.

Whether key material is held in software or in a hardware security module.

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.

Whether rotation is a meaningful question for this key type. Carried explicitly so that a null rotation_enabled is never read as a gap.

Whether automatic rotation is on. Null rather than false where rotation does not apply to the key type at all: false would read as a misconfiguration when the truth is that the concept does not exist for asymmetric, HMAC and custom-key-store keys.

How often the key rotates. Must be distinguishable from absent: a key with no rotation period NEVER rotates, and that reads identically to a missing field unless the absence is declared in unreadable_fields with a not_configured reason.

When the key is scheduled for destruction, where deletion is pending.

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.

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'.