Feature request: SDK-operation input mode (resolve operations to IAM actions)

[LNSHRIVAS]

Feature request: an SDK-operation input mode (resolve operations to IAM actions)

First off, thanks for the tool. policy_sentry is the closest thing to a least-privilege IAM generator that doesn't require a security engineer in the room, and the CRUD/access-level model is a genuinely good abstraction for infrastructure-as-code workflows.

I'm filing this because of a gap I hit working with AI coding agents, and I think it fits the tool's direction. Wanted to check whether it's something you'd consider in scope.

The gap

policy_sentry takes two kinds of input today, both of which assume the user already knows the IAM actions:

• CRUD mode: an access level + resource ARN ("Read on arn:aws:s3:::bucket"), where policy_sentry expands to the actions for that access level
• Actions mode: a list of IAM actions (kms:CreateGrant, ec2:AuthorizeSecurityGroupIngress)

Neither accepts the thing an AI coding agent actually knows before it acts: the SDK operation it is about to call. When a boto3 agent runs s3.put_object, it does not know (and is not well positioned to know) that this maps to s3:PutObject (and for some operations, several actions - dynamodb.transact_write_items needs four). The agent knows the operation; the policy needs the actions; nothing in the current input modes bridges that.

What I'm proposing

An optional input mode (or an addition to actions mode) that takes SDK operations and resolves them to the IAM actions list before generating the policy:

# proposed shape, for illustration
mode: operations
name: 'AgentRole'
operations:
- s3.put_object
- dynamodb.transact_write_items

resolving to the corresponding actions internally before the existing write-policy path takes over.

The operation-to-action mapping is the key piece, and it already exists in machine-readable form: the iam-dataset carries SDK method-to-IAM-action mappings for roughly 19,000 boto3 operations. I've built and published exactly this resolution layer - stigmer.network/opa serves it as a signed OPA bundle, and the MCP server resolves any boto3 operation to its required actions on the fly.

Why it matters

AI coding agents now generate and execute AWS calls routinely, and they are the worst positioned to author IAM policies: they know the operation, not the abstract access level or the action list. A mode that takes "the operation the agent is about to call" and produces the least-privilege policy for it would make policy_sentry the natural fit for that workflow too, not just human IaC.

Alternatives considered

• Generating policies from CloudTrail (Access Analyzer) works but is retrospective - the agent needs the policy before the first call
• Using action mode with a hand-maintained map duplicates what the iam-dataset already provides and goes stale
• Leaving it to the agent to guess IAM actions produces exactly the over-broad Action: "*" policies the tool exists to prevent

Open question

Would an operations-input mode fit policy_sentry's direction? If yes, I'm happy to write it up properly - the resolution layer is already built and published, so the main work is integrating it into the CLI. Happy to discuss the shape first either way.