DynamoDB access governance — every PartiQL statement reviewed before it runs

How AccessFlow connects

The DynamoDB engine is one checksum-pinned download, verified before it loads. It carries the AWS SDK wired to a plain HTTP client rather than the asynchronous default, which keeps a second networking stack out of the download and keeps it small. How an install works →

DynamoDB has no host or port, so the datasource fields are remapped: the database name field holds the AWS region, which is required because the SDK needs it to sign requests even against a custom endpoint; the username is the access key id; the password is the secret access key, AES-256-GCM encrypted at rest and decrypted only when the client is constructed; and the URL override optionally points at DynamoDB Local or a VPC endpoint.

What AccessFlow understands

A submission is either a single PartiQL statement or a JSON table-management command, dispatched on the leading character. PartiQL SELECT, INSERT, UPDATE and DELETE classify as you would expect; the JSON form wraps a single create, delete or update table operation and classifies as DDL, mapping key schema, attribute definitions, billing mode and secondary indexes onto the typed control-plane request.

Grants target the table name, and an index access resolves to its base table so a policy cannot be sidestepped by querying through a secondary index.

What it refuses

Transaction and batch verbs — EXECUTE TRANSACTION and BEGIN — fail closed with HTTP 422. That is the DynamoDB counterpart of the SQL multi-statement ban: a transaction is a carrier for several operations that would have to be reviewed and audited as one, and the governance model is built around a single reviewable statement.

Multi-statement input is rejected, and anything the classifier does not recognise is refused rather than passed through.

Row-level security and masking

Unlike Cassandra, DynamoDB PartiQL can filter on any attribute — a non-key predicate simply becomes a server-side scan filter — so the splice is not restricted to key columns. Policies are ANDed into the WHERE clause with values bound as positional parameters in source order, supporting equality, inequality, the range operators, IN and NOT IN.

An empty value list is the deny-all signal, and the executor returns an empty result without calling DynamoDB at all — PartiQL has no safe constant-false predicate to splice, so short-circuiting is the correct implementation rather than a shortcut. An INSERT into a policied table is rejected, having no WHERE clause to filter.

Masking recurses by dot-path, so a rule on profile.ssn redacts that nested attribute while the rest of the map stays visible.

What the rewrite actually does

A policy restricting the Orders table to the caller's region is ANDed into the WHERE clause — and unlike Cassandra, it does not have to be a key attribute:

-- submitted
SELECT id, email FROM "Orders" WHERE status = 'OPEN';

-- executed (row-security policy: Orders.region = the caller's region)
SELECT id, email FROM "Orders" WHERE (status = 'OPEN') AND region = ?;
--                                                                  ^ positional parameter

A non-key predicate becomes a server-side scan filter, which is why any attribute works here. A deny-all returns an empty result without calling DynamoDB at all — PartiQL has no safe constant-false predicate to splice, so short-circuiting is the correct implementation rather than a shortcut.

Introspection

The connection test lists a single table — the DynamoDB equivalent of a trivial read. Introspection lists tables, reads each key schema so the partition and sort keys are flagged as the primary key, and samples items to derive the remaining attribute names and types, since DynamoDB is schemaless beyond its keys. The schema is named for the region.