Who Can Access This?

Reverse access lookup: which principals can reach a specific supported AWS resource.

Identity-to-Data Intelligence answers: which resources can a specific identity reach? Who Can Access This? inverts the question — starting from a resource, it identifies which principals in the assessed accounts are authorized to access it based on the available access and policy evidence.

The question it answers

Based on the access evidence available to this assessment, which principals could reach this specific resource?

This is useful when you need to reason about the exposure of a specific resource — for example, a sensitive S3 bucket, a KMS key used for encryption, a Secrets Manager secret, or a Lambda function — rather than starting from an identity.

Where to find it

Data SecurityResource drill-down

Open a specific resource in the Data Security view to access the drill-down panel. The Who Can Access This? panel is available within the resource detail view for supported resource types.

Supported resources

The reverse access lookup currently supports the following resource types:

Amazon S3 — S3 buckets assessed for access and data-security context.
AWS KMS — Customer-managed KMS keys.
AWS Secrets Manager — Secrets Manager secrets.
AWS Lambda — Lambda functions.

Note

Supported resource types may expand over time. Consult the Supported AWS Services & Coverage reference for the current list.

Principal categories

The result groups principals into categories based on the authorization evidence available:

Direct IAM grant — principals with an identity policy (directly attached or group-inherited) that grants access to the resource.
Via role assumption — principals who can assume a role that itself has access to the resource.
Via resource policy — principals explicitly named in the resource policy for the resource.
External principals — principals outside the assessed accounts that are represented in the resource policy.
Broad or wildcard access — resource policies or conditions that permit broad access patterns such asPrincipal: "*"(public access) or wide account trust.

Important

The category a principal appears in describes the authorization path observed by the assessment. It does not confirm that the principal has actively accessed the resource or that access would succeed in every runtime context.

Sensitive resource context

For supported resource types, Securitain can present additional context about the security sensitivity of the resource — for example, whether an S3 bucket is publicly accessible, whether a KMS key is used for production encryption, or whether a secret has recently been accessed. This context is evidence-based and is derived from the AWS metadata collected during the assessment.

Sensitivity is evidence-based, not inferred

Classification — where a supported classification signal is present (for example, S3 Intelligent-Tiering class or a public-access configuration), it is reported. It is not inferred from the resource name or ARN.
Encryption — encryption configuration is reported where present in the collected metadata.
Public exposure — public accessibility flags are derived from the AWS resource configuration and Block Public Access settings where available.

Important

The absence of a Data Security scan result for a resource is not the same as the resource being non-sensitive. Securitain does not write “this resource is not sensitive” — it can only describe the evidence that is present, not draw conclusions from absence.

Context and technical risk score

Sensitive resource context is surfaced as additional investigation information. It does not modify the raw technical risk score associated with the access or identity.

What it means

Evidence about the resource's security posture — public access, encryption, classification signals — based on collected AWS metadata.

What it does not mean

A higher raw technical risk score for the identity
Proof that the resource contains regulated or sensitive data
A guarantee that all sensitive resource characteristics have been identified

Resolved and unresolved evidence

Some access paths or principal categories in the Who Can Access This? result may be marked as resolved (Securitain was able to verify the authorization chain from evidence) or unresolved (the policy or relationship exists but the full chain could not be confirmed from available data).

Important

Unresolved access evidence means the authorization chain could not be fully traced — not that access has been disproven. Investigate unresolved results with additional evidence before concluding that access is restricted.

Identity-to-Data vs Who Can Access This?

Identity-to-Data Intelligence

Which resources can this identity reach?

Start from an identity. See all supported data resources it can access.

Who Can Access This?

Which principals can reach this specific resource?

Start from a resource. See all principals that appear to have access.

The two views are complementary. Use Identity-to-Data when investigating an identity's data reach. Use Who Can Access This? when a specific resource is the starting point — for example during incident response, data-exposure review or resource-level access governance.

Evidence and limitations

Who Can Access This? results depend on the authorization evidence available at the time of the last scan:

Only principals from connected accounts are included.
Resource policy collection covers supported types only; unsupported resource types may produce incomplete results.
Conditions in identity and resource policies are not evaluated — an access path may appear when runtime conditions would actually restrict it.
Cross-account principals outside the organization boundary may appear in resource policies but cannot be further resolved.
Scan freshness affects whether recently granted or revoked access is reflected.

Limitation

Absence of a principal in the result does not prove that principal cannot access the resource. Authorization paths that exist outside the current assessment scope will not appear.