Cross-account access in AWS is one of the most commonly misunderstood permission models, because it is never granted by a single policy — it always requires two, on two different sides of an account boundary, and forgetting one half is the single most common cause of a confusing "Access Denied" when both sides look correct in isolation. Cross-Account Access Policy Generator builds exactly one of those two halves: the identity-based policy attached to a user or role in your own account, stating which actions that identity is allowed to attempt against a resource that lives in a different AWS account.
The shape of this statement is intentionally simple: a single Allow effect, an Action list built from whatever you type into the actions textarea (one action per line, such as s3:GetObject or sts:AssumeRole), and a Resource field set to the target ARN you provide — an ARN in another account, identifiable by the account ID segment embedded in the ARN itself. A target-account-ID field is offered purely as an on-page label, so you and anyone reviewing the policy can see at a glance which external account this statement reaches for; it plays no role in the generated JSON, since the ARN itself already carries that information. An optional Sid gives the statement a human-readable name.
What this tool does not do, and says so plainly rather than leaving it implied, is grant the access by itself. AWS evaluates a cross-account request against permissions on both sides of the boundary: your identity policy (built here) must allow the call, and the resource owner in the other account must separately grant it — either through a resource-based policy attached directly to the resource (an S3 bucket policy, an SQS queue policy, a KMS key policy) or, when the target is a role you are assuming rather than a resource you are reading or writing directly, through that role's trust policy naming your account or a specific principal in it as trusted. Build only the identity-policy half here and stop, and the request will fail with an access-denied error that gives no hint the identity policy was actually correct — the missing half was on the other account's side. This tool exists specifically to build the identity-policy half correctly and to make that two-sided requirement explicit, rather than implying that one form and one JSON blob is the whole story.
Because the two halves are built by different people, often in different organizations, and sometimes months apart, keeping them conceptually separate — rather than trying to guess and merge both into one document — is deliberate. This tool's output is a complete, valid, standalone identity-based policy document you can attach to a role or user right away; pairing it with the correct resource-side statement (built with the S3 Bucket Policy Generator or the general Resource-Based Policy Generator elsewhere in this category, or a trust policy from the IAM Trust Policy Generator when the target is a role) is a separate step that has to happen on the other account's side.
Structural validation runs on the assembled document before it is shown — confirming Version, a recognized Effect, a non-empty Action, and a Resource are all present — and the resulting JSON is available to copy or download. Everything, including the account ID label, resource ARN, and action list, is processed entirely in your browser.