Skip to content

feat(bedrockagentcore): add enforcementMode and PolicyStatement.fromPolicy to Policy - #39548

Open
hsiddhu2 wants to merge 1 commit into
aws:mainfrom
hsiddhu2:feat/bedrockagentcore-policy-enforcement-mode
Open

hsiddhu2 wants to merge 1 commit into
aws:mainfrom
hsiddhu2:feat/bedrockagentcore-policy-enforcement-mode

Conversation

@hsiddhu2

Copy link
Copy Markdown

Issue # (if applicable)

Closes #39530.

Reason for this change

AWS::BedrockAgentCore::Policy has two members in Definition (Cedar and Policy) and an EnforcementMode property (ACTIVE or LOG_ONLY). The L2 Policy construct always writes Definition.Cedar.Statement and has no enforcement mode prop. Statements that only the policy member accepts, such as a when guardrails { ... } block or the suppressOutput effect, cannot be declared with the L2, and a policy cannot be rolled out in LOG_ONLY without a property override.

Description of changes

  • PolicyEnforcementMode with ACTIVE, LOG_ONLY and of(), built the same way as PolicyValidationMode.
  • enforcementMode on PolicyProps and AddPolicyOptions. PolicyEngine.addPolicy() passes it through, and Policy exposes it.
  • PolicyStatement.fromPolicy(), which works like fromCedar() (raw, trusted input) and marks the statement for the policy member. Policy writes it to Definition.Policy.Statement.
  • README sections for both.

Design decisions:

  • When enforcementMode is not set, the property is left out of the template, so existing stacks synthesize exactly as before. The service default is ACTIVE per the CreatePolicy API reference.
  • The member is chosen by the statement factory, not by a separate definitionType prop, so a statement and its member cannot get out of sync.
  • Only the stable module is changed. @aws-cdk/aws-bedrock-agentcore-alpha still has its own copy of Policy with the same gap. I left it because the Policy submodule graduated in feat(bedrockagentcore): graduate Policy submodule to stable #38687. Happy to add the same change there if you want it.
  • fromPolicy() does not check the statement's syntax, the same as fromCedar(). The existing length validation still applies, and the service checks the statement at create time.

Describe any new or updated permissions being added

None.

Description of how you validated changes

  • Unit tests: default output unchanged (no EnforcementMode, Cedar member), ACTIVE, LOG_ONLY and of() rendered, fromPolicy() writes the Policy member alone and with LOG_ONLY, addPolicy() passes the mode through, and the length validation still applies to fromPolicy().
  • Integration test integ.policy-enforcement-mode deployed in us-east-1. It creates a Cedar policy in LOG_ONLY and a fromPolicy() policy in LOG_ONLY, then reads both back with GetPolicy and checks enforcementMode, status: ACTIVE and definition.policy.
  • The integ test uses a plain statement in the policy member. A guardrail condition is validated against the output schema of a Gateway tool (the service returned "argument context.output.customer is not present in the context of action AgentCore::Action::"CallTool"" without one), so it would need a Gateway and a tool target in the stack.

Checklist


By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

This branch was previously deployed

1 inactive deployment
automation — 85d30fdc Deployed Oct 29, 2026 by hsiddhu2 via validate-pr #375480
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

beginning-contributor [Pilot] contributed between 0-2 PRs to the CDK bug This issue is a bug. effort/medium Medium work item – several days of effort p2

Projects

None yet

1 participant