DB Access Boundaries

1. The question this answers

The agent tier's route tables and the lockbox tier's route tables both include a route to the DynamoDB gateway endpoint. So both tiers can reach DynamoDB.

Will they share a data store? How is the isolation actually enforced?

2. Different tables, different encryption

So even before any of the four enforcement layers fire, an agent calling DDB cannot accidentally read the lockbox table by name — it's a different resource ARN. The four layers exist to make accessing it impossible even if the ARN is known and explicitly targeted.

3. The four enforcement layers

Reading top-down, each layer is independent of the others. A misconfiguration in one is caught by the next.

4. Layer 1 — Gateway endpoint policy (network)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AgentSubnetsAccessAgentTablesOnly",
      "Effect": "Allow",
      "Principal": "*",
      "Action": [
        "dynamodb:GetItem", "dynamodb:PutItem",
        "dynamodb:UpdateItem", "dynamodb:DeleteItem",
        "dynamodb:Query", "dynamodb:Scan"
      ],
      "Resource": [
        "arn:aws:dynamodb:us-east-1:959228203854:table/ai-sandbox-agent-*"
      ],
      "Condition": {
        "StringEquals": {
          "aws:SourceVpc": "vpc-0ed3a16a8b82f7a34"
        },
        "StringLike": {
          "aws:PrincipalTag/tier": ["sor-reader", "internal"]
        }
      }
    },
    {
      "Sid": "LockboxRoleAccessesLockboxTables",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "*",
      "Resource": [
        "arn:aws:dynamodb:us-east-1:959228203854:table/ai-sandbox-lockbox-*"
      ],
      "Condition": {
        "ArnEquals": {
          "aws:PrincipalArn": "arn:aws:iam::959228203854:role/ai-sandbox-lockbox-service"
        }
      }
    }
  ]
}

Note: this policy ships with the Data module in Step 4a. The DDB gateway endpoint is currently deployed without a custom policy (Step 3); the default policy allows all access. Layer 1 will be locked down when Step 4a applies.

5. Layer 2 — IAM tier role policies (identity)

6. Layer 3 — KMS key policy (cryptographic)

"Statement": [
  {
    "Sid": "EnableRootAccountAdmin",
    "Effect": "Allow",
    "Principal": "arn:aws:iam::959228203854:root"
  },
  {
    "Sid": "AllowLockboxStorageServices",
    "Effect": "Allow",
    "Principal": [
      "s3.amazonaws.com",
      "dynamodb.amazonaws.com"
    ]
  }
]

This is the property called “structural PII-blindness of agents” in the project doctrine. It was the centerpiece verification of Step 2.

7. Layer 4 — Reveal Lambda chokepoint (application)

Agent (has token "tok_abc123")
   │
   │ HTTPS 443 → lockbox-sg
   │   (lockbox-sg only accepts inbound from agent-sg)
   ▼
Reveal Lambda (running in lockbox tier, assumes lockbox service role)
   │
   ├── Authorization check
   │   • caller's IAM role must have can_call_lockbox_reveal=true
   │   • reveal purpose must be in the allowed-reason list
   │   • caller has not exceeded rate limit
   │
   ├── Audit log entry (encrypted with audit CMK)
   │   • caller role, token, timestamp, reason, IP
   │   • this is the SecOps reveal trail
   │
   ├── DDB GetItem on lockbox table
   │   • lockbox service role has access (Layer 2 allows it for this role)
   │   • lockbox CMK decrypts because lockbox service role is in key policy
   │
   └── return PII to caller
                  │
                  ▼
       Caller (now has PII in memory; SHOULD NOT log it; ephemeral use only)

8. Threat model: what gets caught where

For an agent to successfully exfiltrate lockbox PII, four independent configurations would have to be simultaneously wrong. None of these configurations is changed by a single edit; each lives in a different module (network, identity, identity, data) and each requires explicit operator action to relax.

9. Why we share the DDB endpoint rather than have two

It would be possible to deploy two DDB gateway endpoints — one for agent subnets, one for lockbox subnets — and let only the appropriate route tables reach each. We chose one shared endpoint with a scoped policy because:

1. Cost. Gateway endpoints are free, but operationally one is simpler to monitor and audit than two.
2. Enforcement quality. The endpoint policy is the deepest possible scoping for DDB access from inside the VPC. Splitting into two endpoints would push the scope decision into the route table layer, which is coarser-grained (table prefixes vs full resource ARNs and conditions).
3. Auditability. A single endpoint policy is a single artifact in code review. Two endpoints with different policies is two artifacts and the diff between them.
4. Reachability is not access. The doctrine assumes — and demonstrates — that reachability does not constitute access. Building infrastructure that pretends otherwise would teach the wrong lesson.

The shared endpoint is a feature of the design, not a compromise.

10. What is enforced today (post-Step 3) vs. after Step 4a

11. How to view what is enforced today in AWS Console

Two of the four layers exist today (post-Step 3); two are deployed in Step 4a. The viewable artifacts mirror that split.

Today (post-Step 3): Layers 2 and 3 are visible

After Step 4a: Layers 1 and 4 become viewable

The viewing sequence that builds the mental model

1. Open the lockbox CMK key policy. Spend a minute reading the JSON. Note no agent role.
2. Open the agent CMK key policy in another tab. Note the agent roles ARE listed. Side-by-side diff = the boundary visualized.
3. Open the sor-reader inline policy. Find the ReadLockboxTokens Sid. Note it's read-only.
4. Open the internal inline policy in another tab. Search for ReadLockbox. Find nothing. Compare.
5. After Step 4a lands: open the DDB gateway endpoint policy. The endpoint that today permits all access becomes the structural enforcer of "which subnets reach which tables."

12. Doctrine: shared reachability, separated access

The pattern in this document — shared network reachability, independent access controls at multiple layers above — appears repeatedly in the AI-sandbox doctrine:

• Agent and lockbox subnets share the DDB gateway endpoint, but cannot access each other's tables (this document)
• Agent and lockbox subnets share the S3 gateway endpoint, but cannot access each other's buckets (same pattern)
• Agent tier role and internal tier role both have access to Bedrock, but their per-model access is policy-scoped
• Multiple agent tiers can call the gateway, but each is gated by its tier role policy

The general principle: reachability at one layer is acceptable as long as access at higher layers is properly scoped. Removing reachability (running two endpoints, two VPCs, two subnets) is more expensive, more complex, and provides only marginal additional security over a well-scoped multi-layer policy stack. The discipline is to ensure the layers above are actually scoped, not assumed to be.