adr-sml/docs/reference/intake-table-access-verification.md

Who can read adr-intake-submissions — verification extract

Why this file exists. /legal/privacy/ makes a statement to the public about who can see the contents of the intake table. AGENTS.md §4 admits no factual claim that cannot be traced, and CLAUDE.md's R14 rule is that anything a spec claims about must be reachable from the repository — "if the artefact lives only in a console, no reviewer can compare the claim against it and the claim is unverifiable by construction." Until this file existed, that sentence was the one claim on the site whose subject was entirely outside the repo.

Raised by claims-auditor in the D20 cutover audit, 2026-09-01, finding 8.

Provenance. Every figure below was read from AWS on 2026-09-01 with the commands listed at the end, run read-only as arn:aws:iam::327082975128:user/pouya. No command in this file creates or changes anything. Re-run them rather than trusting this file; it is dated for that reason.

---

The claim being checked

src/pages/legal/privacy.astro, §Who can see it:

The table is reachable by the function that writes to it and by one administrative account, which is mine — nobody else has access to the table. There is no team, no assistant and no external administrator.

The finding: it is false

The account has an IAM group admins carrying the AWS managed policy AdministratorAccess, and it has two members: pouya and lars.

iam simulate-principal-policy for dynamodb:GetItem, dynamodb:Query and dynamodb:Scan against arn:aws:dynamodb:ca-central-1:327082975128:table/adr-intake-submissions, across all five IAM users in the account:

principal	GetItem	Query	Scan
user/pouya	allowed	allowed	allowed
user/lars	allowed	allowed	allowed
user/adr-sml-deploy	implicitDeny	implicitDeny	implicitDeny
user/gitea-deploy-meshkinilaw	implicitDeny	implicitDeny	implicitDeny
user/meshkini-backend-deploy	implicitDeny	implicitDeny	implicitDeny

lars holds exactly the access pouya holds, by the same route: membership of admins. The user's own attachments are only IAMUserChangePassword, so the group is the whole of it.

So the published sentence is wrong on both of its halves — a second account has access, and it belongs to a second administrator of a shared account.

The rest of the surface, recorded so the check is complete rather than partial

• 5 IAM users: adr-sml-deploy, gitea-deploy-meshkinilaw, lars, meshkini-backend-deploy, pouya. The three deploy users are all implicitDeny above. adr-sml-deploy's scope is S3 + CloudFront and touches no table (docs/reference/deploy-credential-verification.md).
• 1 IAM group: admins — AdministratorAccess and Billing, two members.
• 33 IAM roles, 26 of them not service-linked. Two carry AdministratorAccess: cdk-hnb659fds-cfn-exec-role-327082975128-ca-central-1 and …-us-east-1. These are AWS CDK bootstrap CloudFormation execution roles, assumable by CloudFormation for stack deployment. They are a real path to the table for anyone who can deploy a CDK stack in this account — which is the two administrators above — rather than a third party.
• adr-intake-lambda-role is the writing principal: dynamodb:PutItem on this table, ses:SendEmail/SendRawEmail, plus AWSLambdaBasicExecutionRole. PutItem only — it cannot read the table, which is worth stating because it is a stronger fact than the page currently claims and it is the part of the sentence that is true.
• No resource-based policy on the table. DynamoDB supports one; this table has none, so access is governed entirely by identity policies.
• The account is not single-project (AGENTS.md §10). lars and the two meshkini*/gitea* users are evidence of that on the IAM surface, not just in the S3 bucket listing §10 describes.

What has to happen before /legal/privacy/ goes public

Tracked as AGENTS.md §9 Q62. It is one of two things and both are Pouya's:

1. Remove the access — take lars out of admins, or replace that membership with a policy that denies DynamoDB on this table — and then this sentence becomes true. Note the likely collision: AGENTS.md Q23 records the Gitea instance as jointly administered and blocked on "its second administrator", so this account is probably not the only thing that access is for.
2. Correct the sentence to what is true. It is a privacy policy, so the honest version is short and specific — the number of people with administrative access, and that the function that writes cannot read.

Do not resolve it by softening. "Access is limited to authorised administrators" is the shape §4 exists to bar: defensible, uninformative, and it would replace a false specific with a true vacancy on the one page where a reader is entitled to the specific.

---

Commands

Run as user/pouya, ca-central-1, all read-only. Exit status read on each; no stderr suppressed anywhere.

aws iam list-users --query 'Users[].UserName'
aws iam list-groups --query 'Groups[].GroupName'
aws iam get-group --group-name admins --query 'Users[].UserName'
aws iam list-attached-group-policies --group-name admins --query 'AttachedPolicies[].PolicyName'
aws iam list-group-policies --group-name admins --query 'PolicyNames'
aws iam list-groups-for-user --user-name lars --query 'Groups[].GroupName'
aws iam list-attached-user-policies --user-name lars --query 'AttachedPolicies[].PolicyName'
aws iam list-user-policies --user-name lars --query 'PolicyNames'

TARN="arn:aws:dynamodb:ca-central-1:327082975128:table/adr-intake-submissions"
for U in pouya lars adr-sml-deploy gitea-deploy-meshkinilaw meshkini-backend-deploy; do
  aws iam simulate-principal-policy \
    --policy-source-arn "arn:aws:iam::327082975128:user/${U}" \
    --action-names dynamodb:GetItem dynamodb:Query dynamodb:Scan \
    --resource-arns "$TARN" \
    --query 'EvaluationResults[].{A:EvalActionName,D:EvalDecision}' --output text
done

# Roles: 33 total, 26 non-service-linked; screened for broad policies.
for R in $(aws iam list-roles --query 'Roles[].RoleName' --output text \
             | tr '\t' '\n' | grep -v '^AWSServiceRole'); do
  aws iam list-attached-role-policies --role-name "$R" \
    --query 'AttachedPolicies[].PolicyName' --output text
done

aws iam get-role-policy --role-name adr-intake-lambda-role \
  --policy-name adr-intake-lambda-inline --query PolicyDocument
aws iam list-attached-role-policies --role-name adr-intake-lambda-role

⚠️ simulate-principal-policy was the tool that produced a false negative on this project once already — AGENTS.md Q22, where eight checks returned empty because 2>/dev/null was hiding an InvalidInput error caused by a zsh parameter-expansion bug ($ACCT:user/ parses :u as a history modifier). The loop above brace-quotes ${U} for that reason, prints one line per principal so a silently-skipped iteration is visible as a missing row, and suppresses nothing. Five rows, or the run did not happen.