Review temporary tenant credentials as a chain, not a token property: who can issue them, what tenant and purpose are bound to the session, which data actions the session can perform, and whether the service still checks the requested resource. For a shared DynamoDB table, verify the role trust and session-tag path, the maximum role permissions, the narrower session policy, the partition-key conditions, batch and transaction behavior, indexes, and revocation. Then run authorized positive and negative checks with disposable tenants against the actual issued credentials. Short expiry limits duration; it does not turn a broad role into a tenant boundary or automatically cancel a session the moment a user loses access.
AWS documents that a role session's permissions normally intersect with its session policy, and that session tags can be referenced through principal-tag conditions. Those are mechanisms, not proof that a tag was derived from a trusted membership or that every data operation is scoped. The review must follow the issuer, role, table, and application code together.
Illustrative case: two accounts in one regional table
Illustrative design review, not a deployed CodeSecPilot result: Cedar and Birch are customer accounts in the same region and table. Cedar's scan worker needs to read one Cedar repository metadata partition and write one Cedar scan-control partition. A credential broker issues a short-lived STS role session tagged for Cedar and attaches an exact-operation session policy. The worker should have no reason to read Birch data or Cedar's protected membership and journal partitions.
A proposed role policy allows reads for every partition beginning with “TENANT#Cedar#”. It prevents the obvious Birch read but also includes Cedar's membership authority and security journal. The review catches this before release. The proposed revision names the allowed record families and actions, prevents a generic table scan, and requires each addressed partition key to match the purpose and tenant bound by the issuer. The application still checks that the requested repository or scan belongs to Cedar and to the permitted work unit. The reviewer does not declare success from reading the policy text; the role trust, resource policies and actual session must be checked.
| Review item | Cedar evidence to request | Failure it is meant to reveal |
|---|---|---|
| Issuer authority | Exact broker principal, trust policy, callers, membership/work grant check | Worker can call STS directly or choose Birch as its own tag |
| Session binding | Region, tenant, purpose, action, resource ID, expiry, source identity | A reusable tenant-wide content grant |
| IAM maximum | Role, session policy, table/index and resource policies | Extra allow outside intended action or partition |
| Data operation | Get/put/query/batch/transaction methods and partition keys | One item in a batch or transaction belongs to Birch |
| Application check | Current actor/work grant, stored parent ownership, output scope | IAM-allowed Cedar record is the wrong repository or sensitive section |
| Revocation | Policy generation and late-job behavior | Old session or queued work proceeds after authority changes |
Trace issuance before inspecting the data policy
Start at the human request or machine delegation. Who authenticates it, checks current tenant membership, confirms a repository entitlement, and selects the action? Where does the broker get the tenant ID: a protected server-side record, or an untrusted request field? Which principal can call STS, and can a worker call STS itself? Record the exact role ARN and region. A tenant value in a queue message, URL, or model output is a selector to validate, not authority.
Review the role trust and the right to set tags together. AWS requires sts:TagSession to pass session tags, and a policy can restrict requested tag keys and values. If arbitrary callers can choose the tenant tag or assume a data role, an apparently precise downstream condition may be bypassed. Also inspect role-session names and source identity for auditability; they are not substitutes for authorization.
List the exact operations the worker needs. For Cedar's read, that may be one partition-bound GetItem. A different operation may need a specific scan-control write. Do not grant a generic read/write package just because the role is short-lived. The session policy should narrow the maximum role policy to the task, while role trust, identity permissions, table/resource policies, and any key permissions are reviewed for bypasses. AWS warns that a resource policy granting directly to a role session principal can add permissions outside the normal session-policy limit; see its session-policy evaluation explanation. Ask whether any such grant exists.
Inspect the partition boundary precisely
DynamoDB's dynamodb:LeadingKeys condition applies to the partition key, not the sort key or fields inside an item. AWS says to use the ForAllValues modifier for this condition. IAM's condition-operator guidance also explains why a Null check matters: a ForAllValues condition may otherwise match when its request context key is absent or empty. Review the exact allowed actions with a non-null key requirement, not merely a policy fragment pasted into a design document.
If a sensitive record is distinguished only by sort key under a broadly allowed partition, LeadingKeys cannot distinguish it from its neighbors. The data model must put protected families behind separate partition keys or use a different independently enforceable boundary. A broad “TENANT#Cedar#*” match may keep Birch out while still letting an ordinary worker read Cedar's protected authorization, journal or unrelated findings. Match the purpose and action as well as the tenant. Avoid allowing Scan as a convenient fallback; AWS's DynamoDB example omits Scan because it can return items beyond the leading-key restriction. Treat secondary indexes and projected attributes as separate output paths and inspect any granted index ARN.
Check multi-item requests. Every member of a batch or transaction must be within the permitted partition set. DynamoDB documents that transactional actions have underlying item permissions. A reviewer should check transaction ConditionCheck as well as Put, Update, Delete and Get; a mixed-tenant transaction must not slip through because only its first item was considered. No table export, stream, backup or administrator action should be treated as a normal item grant.
IAM cannot determine whether an allowed Cedar repository row actually belongs to repository R7, whether its parent scan is current, or whether a result contains a section the caller may view. The application must independently verify the stored ownership chain and output scope. A table condition is a second boundary, not a replacement for the resource check.
Work one exact grant through three independent layers
The following synthetic grant is a review artifact, not an executable IAM policy or a deployed product capability. The caller supplies a job selector; the broker derives tenant, purpose and keys from protected records:
request: { job_id: J7, requested_operation: read_repository_metadata }
trusted grant: tenant=Cedar, repository=R7, job=J7, generation=12,
purpose=scan_input_metadata, state=active
issued read authority: GetItem on table T, partition TENANT#Cedar#REPO#R7
For clarity this session contains only the metadata read. A scan-control writer needs a separately enumerated operation/key grant; it does not inherit generic tenant write access. The real policy must establish the action/resource/condition combination and all other applicable grants.
| Request using the read session | Issuer decision | Intended IAM result | Independent application result |
|---|---|---|---|
| Get Cedar R7 metadata for active J7/generation 12 | Issue after trusted grant check | Allow exact GetItem/key | Allow stored parent and current work grant |
| Get Cedar security journal | No legitimate read grant for this purpose | Deny protected partition | Deny purpose/resource request |
| BatchGet Cedar R7 plus Birch R2 | Batch action not granted | Deny action; no batch permission assumed | Deny unsupported operation/foreign scope |
| TransactGet Cedar R7 metadata | No transactional read purpose in this grant | Deny transactional enclosing operation | Deny unsupported operation |
| Get Cedar R8 | Grant is for R7 only | Deny wrong partition | Deny wrong repository |
| Request with missing purpose or unrecognized job | No issuance | No session exists | Fail before data access |
The mixed-batch row deliberately does not claim that GetItem authority covers BatchGetItem. Transactions differ: GetItem permission also governs Get inside TransactGetItems. To enforce this example's nontransactional read grant, explicitly constrain transactional enclosing operations using dynamodb:EnclosingOperation and verify the denial with the issued session. AWS's DynamoDB transaction IAM guide shows this distinction. If a later feature adds batches or transactions, review their supported permissions and every addressed key separately; an action name alone does not establish the intended API boundary.
Now introduce the revealing failure. The application denies the journal request, so an end-to-end check appears green. Inspection of the actual session shows a tenant-wide partition pattern that would allow the journal read at IAM. The application denial prevented disclosure in that path, but it did not verify the promised independent storage boundary. Record application pass / IAM fail and repair the issued policy. A single “denied” column would conceal the defect.
The corrected acceptance record must name which real credential was used, the actual role/session/resource policy revisions, and where each denial occurred. Use disposable tenants in an authorized environment; no such calls were made for this article. A policy review or simulator result remains evidence about its own scope, not a report of service behavior.
After J7 is canceled and its generation advances to 13, the broker refuses new generation 12 issuance and the application rejects further work under the old grant. The old AWS session may still be technically valid until expiry or applicable permission revocation. That residual window belongs in the record, along with the controls that actually prevent protected operations. A generation field in a job row has no automatic effect on AWS unless an enforcement point uses it.
Review expiry and revocation honestly
STS credentials have an expiry, but a previously issued session may remain usable until expiry unless an applicable denial or role-session revocation mechanism blocks it. Role-wide revocation can affect other sessions. For user offboarding or job cancellation, an application-mediated operation can check current protected authorization and work generation before further access. Direct DynamoDB calls made with issued STS credentials bypass that application check: a canceled job record does not stop an otherwise permitted GetItem. Fence queued work and stop new issuance, then document whether an applicable IAM denial/revocation removes existing authority or whether access remains until expiry. If immediate revocation is required, the design must provide an enforcement point that can deliver it.
After authorized behavioral checks, a final review note could say: “The broker denied Cedar's forged Birch and wrong-purpose issuance requests. Cedar's properly issued metadata-read session permits the named nontransactional GetItem/key operation, denies the checked transactional, Birch and protected-family paths, and the application denies the checked stale and wrong-resource requests at this revision. Any scan-control write requires its own separately evidenced grant.” It should also list untested indexes, restore paths, or failure modes. An IAM simulator or template review alone is not runtime evidence.
Review a scope expansion as a new grant
Suppose Cedar later needs metadata from three repositories. The existing single-key review should not silently become a tenant-wide permission. Have the broker resolve each requested repository through protected work records, describe the required operation, and identify the new key set. Then check the corresponding batch or repeated-item path under the actual issued authority.
A useful change record says what expanded and what did not: three authorized repository metadata partitions, no membership or journal access, no generic scan, and the same cancellation limitation for previously issued direct credentials. This preserves the original purpose boundary while allowing the feature to grow. If the organization instead chooses a broader role, document that changed trust model and its compensating application controls rather than continuing to claim the earlier exact-work-unit storage boundary.
For the next multi-tenant service, take one real credential path and fill the Cedar table before expanding its scope. Use the cloud finding ownership guide when separate teams own the role and application check. The vendor source-exposure checklist covers the data-flow questions beyond database authority.