# Hand a change to the other account's admin

> When a move needs a permission in an account you do not run, Douklar shows the exact statement for that account's admin to apply.

Douklar holds one profile per account, and its worker relay needs no
cross-account grant. Some moves still need a permission on the other side: a source bucket
that another account's role must read, or a key in another account. Douklar
does not apply those changes. It shows the exact statement, and the admin of
that account applies it.

## Where the statements appear

| Where | What it hands over |
|---|---|
| Sync preflight | Key policy and IAM statements when a KMS key check finds a permission missing |
| S3 Batch readiness | Source bucket policy changes the Batch role needs to read the source |
| Common moves, carve-out | A worked example for accounts that share no Organization and no owner |

A read that is denied shows as "unknown" and does not block the run. The
statement names the permission so the other admin can grant it.

## A source bucket another account reads

An S3 Batch job runs as a role in the destination account,
`douklar-s3-batch-operations` unless your deployment names another. Batch
readiness checks the source bucket policy; when the role cannot read the
source, it shows this statement for the source account's admin to merge.
Sample accounts and bucket; the `Sid` suffix is derived from the bucket and
the role:

```json
{
  "Sid": "BatchRoleRead1521f0b6bee729b0",
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::444455556666:role/douklar-s3-batch-operations" },
  "Action": [
    "s3:GetBucketLocation",
    "s3:ListBucket",
    "s3:PutInventoryConfiguration",
    "s3:GetObject",
    "s3:GetObjectTagging",
    "s3:GetObjectVersion",
    "s3:GetObjectVersionTagging"
  ],
  "Resource": [
    "arn:aws:s3:::platform-prod-assets",
    "arn:aws:s3:::platform-prod-assets/*"
  ]
}
```

The worker relay reads as the source profile and writes as the destination
profile, so it needs no change to the source bucket policy.

## A key in another account

A KMS key in another account needs two statements: one in the key policy, in
the account that owns the key, and one IAM statement for the principal that
uses it. Key policy statement:

```json
{
  "Sid": "AllowDouklarMigrationAccount",
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::444455556666:root" },
  "Action": ["kms:GenerateDataKey", "kms:Decrypt"],
  "Resource": "*",
  "Condition": { "StringEquals": { "kms:ViaService": "s3.us-east-1.amazonaws.com" } }
}
```

For a source key, `kms:Decrypt` alone is enough.

Objects on the AWS managed key `aws/s3` can be read only inside their own
account. For those, use the worker relay: it reads as the source account and
writes as the destination account. Preflight blocks the other routes when the
source profile can read the key; otherwise it shows a note naming the key.

## When you choose a destination key

In Review you can choose a **specific KMS key** for the run. Paste the full
key ARN (`arn:aws:kms:<region>:<account>:key/<key id>`); aliases and bare key
IDs are refused, because AWS resolves them in the writer's account. The key
must be in the destination bucket's Region.

## Next

- [Preflight and Review](/docs/douklar/preflight-and-review): what preflight
  reads before a run.
- [Common moves: carve-out or merger](/moves/carve-out).

Source: https://douklar.app/docs/douklar/hand-over-to-the-other-account (Douklar docs, last checked 2026-10-19)