create_policy
¶
create_policy(
name: PolicyName,
definition: PolicyDefinition,
policy_engine_id: ResourceId,
*,
config_overrides: Optional[BedrockAgentCoreControlClientConfig] = None,
description: Optional[Description] = None,
validation_mode: Optional[PolicyValidationMode] = None,
enforcement_mode: Optional[EnforcementMode] = None,
client_token: Optional[ClientToken] = None,
) -> CreatePolicyResponse
Creates a policy within the AgentCore Policy system. Policies provide real-time, deterministic control over agentic interactions with AgentCore Gateway. Using Cedar or Dogwood, you can define fine-grained policies that specify which interactions with Gateway tools are permitted based on input parameters and OAuth claims, ensuring agents operate within defined boundaries and business rules. The policy is validated during creation against the Cedar schema generated from the Gateway's tools' input schemas, which defines the available tools, their parameters, and expected data types. This is an asynchronous operation. Use the GetPolicy operation to poll the status field to track completion.
If the new policy is a temporal policy, creating it invalidates the policy engine's active temporal sessions. For more information about temporal policy sessions, see session-based temporal policies. The policy engine returns an HTTP 409 ConflictException to in-flight sessions. To resume, you must start a new session with a new session ID.
Parameters:
-
name(PolicyName) –The customer-assigned immutable name for the policy. Must be unique within the account. This name is used for policy identification and cannot be changed after creation.
-
definition(PolicyDefinition) –The Cedar or Dogwood policy statement that defines the access control rules. This contains the actual policy logic written in Cedar or Dogwood, specifying effect (permit or forbid), principals, actions, resources, and conditions for agent behavior control.
-
description(Optional[Description], default:None) –A human-readable description of the policy's purpose and functionality (1-4,096 characters). This helps policy administrators understand the policy's intent, business rules, and operational scope. Use this field to document why the policy exists, what business requirement it addresses, and any special considerations for maintenance. Clear descriptions are essential for policy governance, auditing, and troubleshooting.
-
validation_mode(Optional[PolicyValidationMode], default:None) –The validation mode for the policy creation. Determines how Cedar analyzer validation results are handled during policy creation. FAIL_ON_ANY_FINDINGS (default) runs the Cedar analyzer to validate the policy against the Cedar schema and tool context, failing creation if the analyzer detects any validation issues to ensure strict conformance. IGNORE_ALL_FINDINGS runs the Cedar analyzer but allows policy creation even if validation issues are detected, useful for testing or when the policy schema is evolving. Use FAIL_ON_ANY_FINDINGS for production policies to ensure correctness, and IGNORE_ALL_FINDINGS only when you understand and accept the analyzer findings.
-
enforcement_mode(Optional[EnforcementMode], default:None) –The enforcement mode for the policy. Run this policy in
LOG_ONLYmode to collect data on how it affects your application. Once you are satisfied with the data gathered, switch the policy toACTIVE. Defaults toACTIVE. -
policy_engine_id(ResourceId) –The identifier of the policy engine which contains this policy. Policy engines group related policies and provide the execution context for policy evaluation.
-
client_token(Optional[ClientToken], default:None) –A unique, case-sensitive identifier to ensure the idempotency of the request. The Amazon Web Services SDK automatically generates this token, so you don't need to provide it in most cases. If you retry a request with the same client token, the service returns the same response without creating a duplicate policy.
Raises:
-
AccessDeniedException–This exception is thrown when a request is denied per access permissions
-
ConflictException–This exception is thrown when there is a conflict performing an operation
-
InternalServerException–This exception is thrown if there was an unexpected error during processing of request
-
ResourceNotFoundException–This exception is thrown when a resource referenced by the operation does not exist
-
ServiceQuotaExceededException–This exception is thrown when a request is made beyond the service quota
-
ThrottlingException–This exception is thrown when the number of requests exceeds the limit
-
ValidationException–The input fails to satisfy the constraints specified by the service.
-
UnknownServiceError–The service returned an error code this client does not model.
Source code in docs_src/capo_bedrock_agentcore_control/_services/bedrock_agent_core_control.py
12166 12167 12168 12169 12170 12171 12172 12173 12174 12175 12176 12177 12178 12179 12180 12181 12182 12183 12184 12185 12186 12187 12188 12189 12190 12191 12192 12193 12194 12195 12196 12197 12198 12199 12200 12201 12202 12203 12204 12205 12206 12207 12208 12209 12210 12211 12212 12213 12214 12215 12216 12217 12218 12219 12220 12221 12222 12223 12224 12225 12226 12227 12228 12229 12230 12231 12232 12233 12234 12235 12236 12237 12238 12239 12240 12241 12242 12243 12244 12245 12246 12247 12248 12249 12250 12251 12252 12253 12254 12255 12256 12257 12258 12259 12260 12261 12262 12263 12264 12265 12266 12267 | |