PolicyConstraints Object

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.

Whether the policy BLOCKS the action or merely reports it. The field that matters most here: a rule that blocks is far stronger evidence than one that audits. Note that AWS service control policies have no audit or report-only mode at all -- only allow and deny, both effective immediately -- so 'audit' is never emitted for them, and effect is per statement rather than per policy, since a single policy commonly contains both.

Whether the policy is actually in force. No enabled toggle exists at policy or attachment level on AWS; it is derived from the policy type being enabled on the organisation root AND the policy having at least one target, and is flagged as derived.

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.

The policy name as the provider names it.

The provider's own identifier for the policy.

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 node this row reports the policy as applying to.

The level this row's scope node sits at.

Values the policy permits, where the provider exposes them as structured data. Nothing exposes these for AWS service control policies; they could only be heuristically parsed out of arbitrary customer-authored condition blocks, and are left null rather than guessed.

Values the policy forbids, on the same terms as allowed_values.

A friendlier name, where the provider has one separate from policy_name. AWS service control policies have no such field and this falls back to the name.

Whether a sub-account has opted out of an organisation-wide rule -- itself a finding. No such concept exists for AWS service control policies: they intersect and never override, a child can never relax a parent, and there is no exemption mechanism, so this is always false there and that is a fact rather than a gap.

The node the policy is actually attached to, when that differs from scope_ref. Inheritance must be computed on AWS: the attachment operation returns directly attached policies only, and the operation that would merge inheritance explicitly excludes service control policies.

Whether this row is an inherited application rather than a direct attachment.

Parameter values supplied where the policy is instantiated per assignment. AWS service control policies are not parameterised at all -- attaching one to forty nodes attaches the identical document forty times -- so this is null with not_supported_by_provider there.

The raw policy document. Carried in the provider's native encoding: AWS service control policy content is plain JSON, the opposite of IAM policy documents, and applying the IAM decode rule to it mangles the document.

Which preventative policy mechanism this is, as the provider names it.

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 this policy mechanism can express a report-only mode at all, so that the absence of audit policies is not misread as the customer choosing not to use them.

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