An explicit Deny statement is the sharpest tool in IAM's policy language: it is the one thing that unconditionally overrides every Allow, from any policy, attached anywhere to the principal making the request. AWS evaluates every request the same way — deny by default, unless something explicitly allows it, unless something else explicitly denies it, in which case the deny wins regardless of how permissive everything else looks. Deny Policy Generator is a focused builder for that specific, high-leverage statement shape, including the two real branches its structure can take.
The base case is straightforward: pick a Sid, list the actions or resources you want to deny (one per line), and the tool assembles a statement with Effect: "Deny" and either an Action list (deny exactly these API calls, against any resource) or a Resource list (deny access to exactly these resources, for any action) depending on which target you choose. The second, more powerful branch is the NotAction/NotResource toggle. Flip it on while targeting actions, and the same list you entered becomes NotAction instead of Action — which inverts the match entirely: a Deny with NotAction: ["s3:GetObject", "s3:ListBucket"] denies every action whose name is not in that list, a common and deliberate pattern for expressing "deny everything except these specific safe actions" in one statement, rather than enumerating every dangerous action by hand. The same inversion applies to resources via NotResource when the target is set to Resource. This is real branching logic implemented in the statement builder, not a cosmetic label — the JSON field name and its semantics genuinely change based on the toggle.
An optional condition can scope the deny to specific circumstances rather than applying it unconditionally — a region restriction via StringNotEquals on aws:RequestedRegion, an IP restriction, a tag check, or any other IAM condition operator, key, and value you supply, assembled through the same condition-entry helper used across this tool category. Leaving the operator, key, or value blank simply omits the condition, producing an unconditional deny.
The documentation here is deliberately explicit about IAM's real evaluation order, because a wrongly-scoped Deny is one of the easiest ways to silently break access for an entire account: an explicit Deny in any policy attached to a principal — the identity policy, a permissions boundary, or (for resource-based access) the resource policy — beats every Allow, everywhere, with no way to override it from another policy. The only exceptions to this that exist in AWS are handled at the AWS Organizations level (Service Control Policies and resource control policies) and certain root-user behaviors, which this tool does not model or claim to account for — it builds a single, standard IAM policy statement and validates its structure, nothing more.
The result is a validated, ready-to-attach Deny statement, wrapped in a full policy document, with the NotAction/NotResource branch and any condition applied exactly as configured — assembled and checked entirely in your browser.